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