Async flip is not supported with Indexed 8 bit format as it depends on
LUT and can't be updated atomically.
Note: This may change the alignment for C8 framebuffers on some
platforms.
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20250407-asyn-v13-5-b93ef83076c5@intel.com
Hook up the newly added plane function pointer
format_mod_supported_async to populate the modifiers/formats supported
by asynchronous flips.
v5: Correct the if condition for modifier support check (Chaitanya)
v6: Replace uint32_t/uint64_t with u32/u64 (Jani)
v7: Move plannar check from intel_async_flip_check_hw() to
intel_plane_format_mod_supported_async() (Ville)
v8: In case of error print format/modifier (Chaitanya)
v9: Exclude C8 format as its not supported by hardware
v10: filter only planar formats
move changes in can_async_flip to new patch (Ville)
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20250407-asyn-v13-4-b93ef83076c5@intel.com
The function intel_plane_can_async_flip() checks for async supported
modifier, add format support check also in the same function.
Note: on ADL the surface base addr is required to be 16k aligned and if
not might generate DMAR and GGTT faults leading to glitches. This patch
changes the 16k alignment to 4k for planar formats.
v11: Move filtering Indexed 8bit to a separate patch (Ville)
v12: correct the commit msg and remove unwanted debug print (Ville)
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20250407-asyn-v13-3-b93ef83076c5@intel.com
The compat i915_drv.h contains things that aren't there in the original
i915_drv.h. Split out gem/i915_gem_object.h and i915_scheduler_types.h,
moving the corresponding pieces out, including FORCEWAKE_ALL to
intel_uncore.h.
Technically I915_PRIORITY_DISPLAY should be in i915_priolist_types.h,
but it's a bit overkill to split out another file just for
that. i915_scheduler_types.h shall do.
With this, the compat i915_drv.h becomes a strict subset of the
original.
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/d6bd95bf52aa37f48ddec3e675b7a3cc66829eef.1741192597.git.jani.nikula@intel.com
[Jani: fix i915_gem_object.h header guard while applying]
Signed-off-by: Jani Nikula <jani.nikula@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
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
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
Decode the display faults a bit more extensively so that one
doesn't have to translate the bitmask to planes/etc. manually.
Also for plane faults we can read out a bit of state from the
relevant plane(s) and dump that out.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250217070047.953-4-ville.syrjala@linux.intel.com
Include the standard "[PLANE:%d:s]" stuff in all plane debugs
(or rather all I was able to find), to provide better information
on which plane we're actually talking about.
There are a few spots where we care about the CRTC as well, so
include that where appropriate.
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206185533.32306-13-ville.syrjala@linux.intel.com
Using the plane->state pointer in the tracepoints is incorrect
as technically a different state could already have been swapped
in (though in reality that is currently prevented by the stall
hacks in the commit machinery). But let's not leave such footguns
lying around when we can just pass in the correct state by hand.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241218173650.19782-4-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
i915 has this really nice, infrastructure where everything becomes
complicated, GGTT needs eviction, etc..
Lets not do that, and make the dumbest possible interface instead.
Try to retrieve the VMA from old_plane_state, or intel_fbdev if kernel
fb.
Link: https://patchwork.freedesktop.org/patch/msgid/20241206182032.196307-1-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Tested-by: Jani Saarinen <jani.saarinen@intel.com>
Add a helper to the relative data rate handling in skl_watermarks.c
where other similar functions are implemented. Also get rid of
use_min_ddb() and use use_minimal_wm0() instead to decide whether
the relative data rate can be returned as 0
v2: re-phrase the commit description (uma)
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241121112726.510220-3-vinod.govindapillai@intel.com
Use x100, or ver * 100 + rel, versions for full IP version checks,
similar to what xe driver does:
- Replace IP_VER(14, 1) inline with 1401, etc.
- Convert DISPLAY_VER_FULL() to DISPLAY_VERx100()
- Convert IS_DISPLAY_VER_FULL() to IS_DISPLAY_VERx100()
- Convert IS_DISPLAY_VER_STEP() to IS_DISPLAY_VERx100_STEP()
This makes ver.rel versions easier to use, follows the xe driver
pattern, and drops the dependency on the IP_VER() macro.
v2: Rebase, drop IP_VER() from xe compat headers
v3: Rebase
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241029155536.753413-1-jani.nikula@intel.com
Disable the support for odd panning in x direction.
v2: Replace HSD with WA in commit message [Suraj]
Modified the condition for handling odd panning
v3: Simplified the condition for checking hsub
Using older framework for wa as rev1[Jani]
v4: Modify the condition for hsub [Sai Teja]
Initialize hsub in else path [Dan]
v5: Replace IS_LUNARLAKE with display version.
Resolve nitpicks[Jani]
v6: Replace -EINVAL with hsub [Suraj]
Remove src_w check as not required
v7: Remove check for NV12.
Add check for PTL as well [Matt]
v8: Alignment fix
Continuing discussions from:
https://patchwork.freedesktop.org/series/136416/
Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241028044153.1605209-1-nemesa.garg@intel.com
We need to be able to do both MMIO and DSB based pipe/plane
programming. To that end plumb the 'dsb' all way from the top
into the plane commit hooks.
The compiler appears smart enough to combine the branches from
all the back-to-back register writes into a single branch.
So the generated asm ends up looking more or less like this:
plane_hook()
{
if (dsb) {
intel_dsb_reg_write();
intel_dsb_reg_write();
...
} else {
intel_de_write_fw();
intel_de_write_fw();
...
}
}
which seems like a reasonably efficient way to do this.
An alternative I was also considering is some kind of closure
(register write function + display vs. dsb pointer passed to it).
That does result is smaller code as there are no branches anymore,
but having each register access go via function pointer sounds
less efficient.
Not that I actually measured the overhead of either approach yet.
Also the reg_rw tracepoint seems to be making a huge mess of the
generated code for the mmio path. And additionally there's some
kind of IS_GSI_REG() hack in __raw_uncore_read() which ends up
generating a pointless branch for every mmio register access.
So looks like there might be quite a bit of room for improvement
in the mmio path still.
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240930170415.23841-12-ville.syrjala@linux.intel.com
The ilk+ disable_lp_wm boolean has the exact same role as
disable_cxsr for gmch platforms. The documentation also
still talks about CxSR on ilk+ even theough the way you
control it has now change to involve toggling the LP watermarks.
Get rid of disable_lp_wm and just use disable_cxsr for ilk+
as well.
TODO: Unify even more to not have any gmch vs. ilk+
details in high level modeset code...
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240916162413.8555-7-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
As with other watermark calculations, the dodgy pre-g4x
update_wm_{pre,post} flag calcultion would like to know
if a modeset is about to happen or not, and technically
later stages in the atomic_check() may still flag one.
In practice that shouldn't happen as we don't have dynamic
CDCLK implemented for these old platforms.
Regardless it'll be nice to move this old cruft out from
the supposedly platform agnostic plane code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240916162413.8555-6-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
intel_wm_need_update() is a mess when it comes to variable
names and constness. The checks also keep alternating randomly
between 'old != cur' vs. 'cur != old'. Clean it all up.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240916162413.8555-5-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Pull the ilk/snb/ivb LP watermark disable checks into a separate
function similar to the gmch counterpart (i9xx_must_disable_cxsr()).
Reduces the clutter in intel_plane_atomic_calc_changes() significantly.
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240916162413.8555-4-ville.syrjala@linux.intel.com
In case of legacy cursor update, the cursor VMA needs to be unpinned
only after vblank. This exceeds the lifetime of the whole atomic commit.
Any trick I attempted to keep the atomic commit alive didn't work, as
drm_atomic_helper_setup_commit() force throttles on any old commit that
wasn't cleaned up.
The only option remaining is to remove the plane from the atomic commit,
and use the same path as the legacy cursor update to clean the state
after vblank.
Changes since previous version:
- Call the memset for plane state immediately when scheduling vblank,
this prevents a use-after-free in cursor cleanup.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240522053341.137592-4-maarten.lankhorst@linux.intel.com
According to BSpec we now should call "master" pipes, "primary" pipes
and "slave" pipes, should be "secondary" pipes.
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
[vsyrjala: Don't rename port sync stuff, catch a few more things]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240603112551.6481-3-stanislav.lisovskiy@intel.com
Lets unify both bigjoiner and ultrajoiner under simple "joiner" name,
because in future we might have multiple configurations, involving
multiple bigjoiners, ultrajoiner, however it is possible to use
same api for handling both.
v2: - Renamed back some bigjoiner specific parts for now(Ville)
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
[vsyrjala: Catch a few more cases]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240607075457.15700-1-stanislav.lisovskiy@intel.com
Rename need_async_flip_disable_wa to need_async_flip_toggle_wa to
better reflect the fact that we need to deal with the bad
PLANE_CTL_ASYNC_FLIP double buffering behaviour going both
ways.
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240430095639.26390-6-ville.syrjala@linux.intel.com
On bdw-glk the sync->async flip change takes an extra frame due to
the double buffering behaviour of the async flip plane control bit.
Since on skl+ we are now explicitly converting the first async flip
to a sync flip (in order to allow changing the modifier and/or
ddb/watermarks) we are now taking two extra frames until async flips
are actually active. We can drop that back down to one frame by
setting the async flip bit already during the sync flip.
Note that on bdw we don't currently do the extra sync flip (see
intel_plane_do_async_flip()) so technically we wouldn't have
to deal with this in i9xx_plane_update_arm(). But I added the
relevant snippet of code there as well, just in case we ever
decide to go for the extra sync flip on pre-skl platforms as
well (we might, for example, want to change the fb stride).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240430095639.26390-5-ville.syrjala@linux.intel.com
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
With Xorg+modesetting on skl+ we see the following behaviour:
1. root pixmap is X-tiled
2. client submitted buffers can be Y-tiled (w/ 'Option "dmabuf_capable"')
3. we try to switch from the X-tiled buffer to the Y-tiled buffer
using an async flip (when vsync is disabled).
4. the async flip will be rejected by i915 due to the modifier change
Relax the rules a bit by turning the first async flip into a sync
flip so that we can change the modifier if necessary. Note that
we already convert the first async flip into a sync flip on adl+
in order to reprogram the watermarks.
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240430095639.26390-4-ville.syrjala@linux.intel.com
This reverts commit cfeff354f7.
A core design consideration with legacy cursor updates is that the
cursor must not touch any other plane, even if we were to force it
to take the slow path. That is the real reason why the cursor uses
a fixed ddb allocation, not because bspec says so.
Treating cursors as any other plane during ddb allocation
violates that, which means we can now pull other planes into
fully unsynced legacy cursor mailbox commits. That is
definitely not something we've ever considered when designing
the rest of the code. The noarm+arm register write split in
particular makes that dangerous as previous updates can get
disarmed pretty much at any random time, and not necessarily
in an order that is actually safe (eg. against ddb overlaps).
So if we were to do this then:
- someone needs to expend the appropriate amount of brain
cells thinking through all the tricky details
- we should do it for all skl+ platforms since all
of those have double buffered wm/ddb registers. The current
arbitrary mtl+ cutoff doesn't really make sense
For the moment just go back to the original behaviour where
the cursor's ddb alloation does not change outside of
modeset/fastset. As of now anything else isn't safe.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231213102519.13500-10-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
We are preparing for Xe driver. Xe driver doesn't have i915_sw_fence
implementation. Lets drop i915_sw_fence usage from display code and
use dma_fence interfaces directly.
For this purpose stack dma fences from related objects into new plane
state. Drm_gem_plane_helper_prepare_fb can be used for fences in new
fb. Separate local implementation is used for Stacking fences from old fb
into new plane state. Then wait for these stacked fences during atomic
commit. There is no be need for separate GPU reset handling in
intel_atomic_commit_fence_wait as the fences are signaled when GPU hang is
detected and GPU is being reset.
v4:
- Drop to_new_plane_state suffix from add_dma_resv_fences
- Use dma_resv_usage_rw(false) (DMA_RESV_USAGE_WRITE)
v3:
- Rename add_fences and it's parameters
- Remove signaled check
- Remove waiting old_plane_state fences
v2:
- Add fences from old fb into new_plane_state->uapi.fence rather than
into old_plane_state->uapi.fence
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231031084557.1181630-1-jouni.hogander@intel.com
We now start calculating relative plane data rate for cursor plane as
well, as instructed by BSpec and also treat cursor plane same way as
other planes, when doing allocation, i.e not using fixed allocation for
cursor anymore.
Bspec: 68907
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-7-lucas.demarchi@intel.com
BSpec clearly instructs us to use plane scale factor when calculating
relative data rate to be used when allocating DDB blocks for each plane.
For some reason we use scale factor for data_rate calculation, which is
used for BW calculations, however we are not using it for DDB calculations.
So lets fix it as described in BSpec 68907.
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Garg, Nemesa <nemesa.garg@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230719104833.25366-1-stanislav.lisovskiy@intel.com
Prepare for re-enabling -Wunused-but-set-variable.
for_each_new_intel_plane_in_state() requires passing in a struct
intel_plane_state pointer, which it uses, but in many places this leads
to warning about unused but set variables. Annotate them with
__maybe_unused.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/438ff3b257b7f85ecca5750ae8687336faee0a79.1685119007.git.jani.nikula@intel.com
intel_atomic_get_new_crtc_state can return NULL, unless crtc state wasn't
obtained previously with intel_atomic_get_crtc_state, so we must check it
for NULLness here, just as in many other places, where we can't guarantee
that intel_atomic_get_crtc_state was called.
We are currently getting NULL ptr deref because of that, so this fix was
confirmed to help.
Fixes: 74a75dc908 ("drm/i915/display: move plane prepare/cleanup to intel_atomic_plane.c")
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230505082212.27089-1-stanislav.lisovskiy@intel.com
