FBDEV ggtt is not restored correctly, add missing GGTT flag to
intel_fbdev_fb_alloc to make it work. This ensures that the global
GGTT mapping is always restored on resume. The GGTT mapping would
otherwise be created in intel_fb_pin_to_ggtt() by intel_fbdev anyway.
This fixes the fbdev device not working after resume.
Fixes: 67a98f7e27 ("drm/xe/display: Re-use display vmas when possible")
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250305110106.564366-1-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Since commit d59cf7bb73 ("drm/i915/display: Use dma_fence interfaces
instead of i915_sw_fence") we don't have anyone waiting on the
I915_RESET_MODESET bit, and there's no need for its semantics. Instead,
simply return true from intel_display_reset_prepare() to indicate that
intel_display_reset_finish() should be called.
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/294690db3fae8fec7f356edf467e79882ed494db.1741001054.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Add a helper for checking if we want to test display reset regardless of
whether it's strictly necessary. This will come in handy in follow-up
work where we want to check this from gt reset side.
v2: Drop superfluous newline
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/487dec72f753302cd565c3a8164afa7fc1e12ed7.1741001054.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
During enabling FBC, for the very first frame, the prepare dirty
rect routine wouldnt have executed as at that time the plane
reference in the fbc_state would be NULL. So this could make
driver program some invalid entries as the damage area. Though
fbc hw ignores the dirty rect values programmed for the first
frame after enabling FBC, driver must ensure that valid dirty
rect coords are programmed. So ensure that for the first frame
correct dirty rect coords are updated to the HW.
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-10-vinod.govindapillai@intel.com
It is not recommended to have both FBC dirty rect and PSR2
selective fetch be enabled at the same time. Mark FBC as not
possible, if PSR2 selective fetch is enabled.
v2: fix the condition to disable FBC if PSR2 enabled (Jani)
v3: use HAS_FBC_DIRTY_RECT()
v4: Update to patch description
Bspec: 68881
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-9-vinod.govindapillai@intel.com
Dirty rectangle feature allows FBC to recompress a subsection
of a frame. When this feature is enabled, display will read
the scan lines between dirty rectangle start line and dirty
rectangle end line in subsequent frames.
Use the merged damage clip stored in the plane state to
configure the FBC dirty rect areas.
v2: - Move dirty rect handling to fbc state (Ville)
v3: - Use intel_fbc_dirty_rect_update_noarm (Ville)
- Split plane damage collection and dirty rect preparation
- Handle case where dirty rect fall outside the visible region
v4: - A state variable to check if we need to update dirty rect
registers in case intel_fbc_can_flip_nuke() (Ville)
v5: - No need to use a separate valid flag, updates to the
conditions for prepare damage rect (Ville)
- Usage of locks in fbc dirty rect related functions (Ville)
v6: - updates dirty rect handling (Ville)
v7: - Loop through all planes in atomic state is good enough (Ville)
Bspec: 68881, 71675, 73424
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-8-vinod.govindapillai@intel.com
If FBC is already active, we don't need to call FBC activate
routine again unless there are changes to the fences. So skip
this on all platforms that don't have fences. Any FBC register
updates done after enabling the dirty rect support in xe3 will
trigger nuke by FBC which is counter productive to the fbc
dirty rect feature.
The front buffer rendering sequence will call intel_fbc_flush()
and which will call intel_fbc_nuke() or intel_fbc_activate()
based on FBC status explicitly and won't get impacted by this
change.
v2: use HAS_FBC_DIRTY_RECT()
move this functionality within intel_fbc_activate()
v3: update to intel_fbc_activate logic (Ville)
update to the patch description
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-7-vinod.govindapillai@intel.com
Introduce a macro to check if the platform supports FBC dirty
rect capability.
v2: - update to the patch subject
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-6-vinod.govindapillai@intel.com
Userspace can pass damage area clips per plane to track
changes in a plane and some display components can utilze
these damage clips for efficiently handling use cases like
FBC, PSR etc. A merged damage area is generated and its
coordinates are updated relative to viewport and HW and
stored in the plane_state. This merged damage areas will be
used for FBC dirty rect support in xe3 in the follow-up
patch.
Big thanks to Ville Syrjala for his contribuitions in shaping
up of this series.
v1: - Move damage_merged helper to cover bigjoiner case and use
the correct plane state for damage find helper (Ville)
- Damage handling code under HAS_FBC_DIRTY_RECT() so the
the related part will be executed only for xe3+
- Changed dev_priv to i915 in one of the functions
v2: - damage reported is stored in the plane state after coords
adjustmentments irrespective of fbc dirty rect support.
- Damage to be empty in case of plane not visible (Ville)
- Handle fb could be NULL and plane not visible cases (Ville)
v3: - No need to empty damage in case disp ver < 12 (Ville)
- update to the patch subject
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-4-vinod.govindapillai@intel.com
Add a const qualifier for the "state" parameter as well as we could
use this helper to get the combined damage in cases of const
drm_plane_state as well. Needed mainly for xe driver big joiner cases
where we need to track the damage from immutable plane state.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-3-vinod.govindapillai@intel.com
In the interest of limiting the display dependencies on i915 core
headers, split out i915_gtt_view_types.h from i915_vma_types.h, and only
include the new header from intel_display_types.h.
Reuse the new header from xe compat code too, failing build if partial
view is used in display code.
Side note: Why would we ever have set enum i915_gtt_view_type values to
size of each type?! What an insane hack.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bb31885c32dbddad76d634c6fdb98a73b546b42e.1740412806.git.jani.nikula@intel.com
With the primary goal of removing #include "i915_vma.h" from
intel_display_types.h, move intel_plane_ggtt_offset() to a proper
function in intel_atomic_plane.c. This reveals tons of implicit
dependencies all over the place that we pulled in via i915_vma.h. Fix
the fallout.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/70ac6d19518f355abf37ac8c4b0f1d18878be28c.1740412806.git.jani.nikula@intel.com
It's undesirable to have to figure out the pxp pointer in display
code. For one thing, its type is different for i915 and xe.
Since we can figure the pxp pointer out in the pxp code from the gem
object, offload it there.
v2: Rebase
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250228114527.3091620-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Move hdcp_mutex, num_hdcp_streams, hdcp_auth_status, hdcp_port_data, and
hdcp_mst_type1_capable members of struct intel_digital_port under an
hdcp sub-struct to group hdcp related things together.
Rename them mutex, num_streams, auth_status, port_data, and
mst_type1_capable for clarity.
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9da4be57b068acd06dec8b93977f0a70627103d4.1740746939.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Move active_mst_links, mst_encoders[], and mst_mgr members of struct
intel_dp under an mst sub-struct to group mst related things together.
Rename them active_links, stream_encoders[] and mgr for clarity.
Note that is_mst and mst_detect are not included, as they're also
relevant for non-mst. The sub-struct is for active mst.
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6f282f90bfe2dd9162e2dee8f681c84313971992.1740746939.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
In the hope of contributing to type safety in our code, let's ensure
that the type returned by the POWER_DOMAIN_*() macros is always of type
enum intel_display_power_domain.
v2:
- Remove accidental +1 in definition of POWER_DOMAIN_PIPE(). (Jani)
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250227-improve-type-safey-power-domain-macros-v3-2-b6eaa00f9c33@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Although we have comments in intel_display_limits.h saying that the
code expects PIPE_A and TRANSCODER_A to be zero, it doesn't hurt to add
them as explicit base values for calculating the power domain offset in
POWER_DOMAIN_*() macros.
On the plus side, we have that this:
* Fixes a warning reported by kernel test robot <lkp@intel.com>
about doing arithmetic with two different enum types.
* Makes the code arguably more robust (in the unlikely event of those
bases becoming non-zero).
v2:
- Prefer using explicit base values instead of simply casting the
macro argument to int. (Ville)
- Update commit message to match the new approach (for reference, the
old message subject was "drm/i915/display: Use explicit cast in
POWER_DOMAIN_*() macros").
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202502120809.XfmcqkBD-lkp@intel.com/
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250227-improve-type-safey-power-domain-macros-v3-1-b6eaa00f9c33@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Wa_14020863754 applies to the display IP, so we should be checking on
display IP version instead of platform. So, let's replace
display->platform.battlemage with the proper IP version check (14.01 for
Xe2_HPD).
Furthermore, for workarounds, we should be checking on full IP versions
to avoid applying the workaround to some variant of the IP that could
theoretically appear in the future (which is likely to have a different
minor release number), since the issue addressed by the workaround could
be fixed in such new release.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250227-xe3lpd-wa-14020863754-v2-1-92b35de1c563@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Have DSB perform plane scaler programming as well. Changes
to pfit/pipe scaler are not being done on the dsb since those
take the fastset path. However we do now allow DSB based plane
updates when the pfit/pipe scaler is currently enabled (the
pfit/pipe scaler just won't be touched by the DSB).
Fortunately the hardware issue where some scaler registers
are latched at frame start and some at start of vblank has
been fixed on icl+ (IIRC), and since DSB is tgl+ only we
don't have to do any changes to the DSB vblank evasion.
Not that we handle that hardware issue correctly in the
CPU vblank evasion either...
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250218205850.1422-4-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shakar@intel.com>
We don't actually need any planes to get updated in order
to perform the commit on the DSB. Allow DSB based updates
even when we don't touch planes. The main benefit here
is that pure LUT updates will now go through the DSB path
and therefore we don't have to do vblank evasion/etc. on
the CPU.
I think the reason I had this excluded was that I was
originally contemplating using frame/flip timestamps as
a way to complete the commits. But I had to scrap that
idea when it turned out that those timestamp get
corrupted when DSB is poking at random registers.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250218205850.1422-2-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
