Do not schedule vblank worker for LUT update if the registers are
double buffered
v2: Do not schedule the worker at all (Ville)
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://lore.kernel.org/r/20250523062041.166468-12-chaitanya.kumar.borah@intel.com
We have extended using vblank DC workaround mechanism for
Wa_16025596647. Rename related functions and variables:
vblank_wa_num_pipes -> vblank_enable_count
vblank_dc_work -> vblank_notify_work
intel_display_vblank_dc_work -> intel_display_vblank_notify_work
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250414100508.1208774-14-jouni.hogander@intel.com
Scope of intel_psr_needs_block_dc_vblank has changed now. Rename it as
intel_psr_needs_vblank_notification. Also rename
intel_crtc::block_dc_for_vblank as intel_crtc:vblank_psr_notify
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250414100508.1208774-13-jouni.hogander@intel.com
We don't really want legacy cursor updates to trigger
VRR pushes because these can happen willy nilly and we
generally want more precise control over the pushes.
The fastpath in intel_legacy_cursor_update() doesn't
send pushes, but if we punt to the full commit path
(with the flip completion short circuited) we are currently
sending pushes. Skip those as well so that they don't
interfere with the push handling from normal commits.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250207223159.14132-3-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
struct intel_display will replace struct drm_i915_private as
the main thing for display code. Convert the skl+ universal plane
code to use it.
Note that we still have two straggles in the form on
HAS_FLAT_CCS() and the pxp stuff.
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-11-ville.syrjala@linux.intel.com
intel_sprite.c was partially converted to struct intel_display.
Finish the job now that we can deal with the platform checks
as well.
And while at it we also move the 'display' variable declaration
to be the first thing in most functions, consistency. We can
actually do that now since intel_display() accepts the intel_plane
and intel_plane_state types.
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-9-ville.syrjala@linux.intel.com
Fix all typos in files under drm/i915/display reported by codespell tool.
v2:
- Include british and american spelling, as those are
not typos.
- Fix commenting style. <Jani>
v3: Fix "In case" wrongly capitalized and
also fix comment style. <Krzysztof Niemiec>
Signed-off-by: Nitin Gote <nitin.r.gote@intel.com>
Reviewed-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250120081517.3237326-8-nitin.r.gote@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Plumb the DSB down into intel_vrr_send_push() so that we can
perform the opration on the DSB.
TRANS_PUSH, being a transcoder register, needs non-posted writes
to make it through.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-17-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Convert I915_STATE_WARN() to struct intel_display *, and rename to
INTEL_DISPLAY_STATE_WARN(). Do some minor opportunistic struct
drm_i915_private to struct intel_display conversions while at it.
v2: crtc_state may be NULL in intel_connector_verify_state()
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241024162510.2410128-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Push regular plane/color management updates to the DSB,
if other constraints allow it.
The first part of the sequence will go as follows:
- CPU will kick off DSB0 immediately
- DSB0 writes double bufferd non-arming registers
- DSB0 evades the vblank
- DSB0 writes double buffered arming registers
If no color management updates is needed we follow that up with:
- DSB0 waits for the undelayed vblank
- DSB0 waits for the delayed vblank (usec wait)
- DSB0 emits an interrupt which will cause the CPU to complete the commit
If color management update is needed:
- DSB0 will start DSB1 with wait for undelayed vblank
- DSB0 will in parallel perform the force DEwake tricks
- DSB1 writes single buffered LUT registers
- DSB1 waits for the delayed vblank (usec wait)
- DSB1 emits an interrupt which will cause the CPU to complete the commit
With this sequence we don't need to increase the vblank delay
to make room for register programming during vblank, which is
a good thing for high refresh rate display. But I'll need to
still think of some way to eliminate VRR commit completion
related races under this scheme.
Stuff that isn't ready for DSB yet:
- modesets (potentially we could do
at least the plane enabling via DSB)
- fastsets
- VRR
- PSR
- scalers
- async flips
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-14-ville.syrjala@linux.intel.com
Introduce intel_scanlines_to_usecs() as a counterpart to
intel_usecs_to_scanlines().
We'll have some use for this in DSB code as we want to do
relative scanline waits to evade the delayed vblank, but
unfortunately DSB can't do relative scanline waits (only
absolute). So we'll instead convert the relative scanline
count to usec and do a relative usec wait instead (which the
DSB knows how to do).
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-9-ville.syrjala@linux.intel.com
We need to block DC6 entry in case of Panel Replay as enabling VBI doesn't
prevent DC6 in case of Panel Replay. This causes problems if user-space is
polling for vblank events.
Fix this by setting target DC state as DC_STATE_EN_UPTO_DC5 when both
source and sink are supporting eDP Panel Replay and VBI is enabled.
v4:
- s/vblank_work/vblank_dc_work/
- changed type of block_dc_for_vblank to bool
v3:
- do flush_work for vblank_work on intel_crtc_vblank_off
- no need to use READ_ONCE in bdw_enable_vblank
- check crtc->block_dc_for_vblank in bdw_disable_vblank as well
- move adding block_dc_for_vblank into this patch
v2:
- use READ_ONCE in intel_display_vblank_work
- use DC_STATE_DISABLE instead of DC_STATE_EN_UPTO_DC6
- use intel_crtc->block_dc6_needed
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2296
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240920062340.1333777-3-jouni.hogander@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
Dotclocks can reach ~1GHz these days, so intel_usecs_to_scanlines(),
with its 32bit maths, is currently limited to a few milliseconds.
I want bigger numbers in DSB selftests, so switch over to 64bit
maths.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240528185647.7765-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
In intel_crtc_vblank_work(), we access uapi.event before grabbing the
event_lock spinlock, but modify it inside the spinlock block. This
causes some static analyzers to get confused and issue a warning.
The uapi.event value is not protected by the event_lock, so we can
safely move it out of the protected block to prevent false positives.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240528112901.476068-3-luciano.coelho@intel.com
Using PLANE_PRIMARY + PLANE_SPRITE? on skl+ results in a bunch
of unnecessary head scratching. Add aliases using the skl+ plane
names.
And for pre-skl we only need to keep PRIMARY,SPRITE0,SPRITE1
as we only ever have 0-2 sprites per pipe on those platforms.
v2: Don't break icl_nv12_y_plane_mask() (Jani)
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240517171208.21313-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
There isn't really any reason to make the caller suffer through
checking the vblank evasion min/max scanlines. If we somehow
ended up with bogus values (which really shouldn't happen)
then just skip the actual vblank evasion loop but otherwise
plow ahead as normal.
The only "real" change is that we now get+put a vblank reference
even if the min/max values are bogus, previously we skipped
directly to the end.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231213102519.13500-7-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Collect the information needed for vblank evasions into
a structure that we can pass around more easily.
And let's rename intel_crtc_vblank_evade_scanlines() to just
intel_vblank_evade_init() so that better describes the intended
usage of initializing the context.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231213102519.13500-4-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Drop the vblank reference only after we've done the hideous
need_vlv_dsi_wa stuff. This will make it easier to reuse the
the vblank evasion machinery elsewhere.
Keeping the vblank reference for a bit longer is not a
problem. In fact we might want to not drop it at all until
intel_pipe_update_end(), but we'll leave that idea for later.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231213102519.13500-3-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
We'll be needing to do vblank evasion around legacy cursor updates,
which don't have the intel_atomic_state around. So let's remove
this dependency on a full commit and pass the crtc state in by hand.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231213102519.13500-2-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Assuming crtc->state is pointing at the correct thing for the
async flip commit is nonsense. If we had already queued up multiple
commits this would point at the very lates crtc state even if the
older commits hadn't even happened yet.
Instead properly stage/arm the event like we do for async flips.
Since we don't need to arm multiple of these at the same time we
don't need a list like the normal vblank even processing uses.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230928152450.30109-1-ville.syrjala@linux.intel.com
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
At the moment a modeset fails if the config computation of a pipe can't
fit its required BW to the available link BW even though the limitation
may be resolved by reducing the BW requirement of other pipes.
To improve the above this patch adds helper functions checking the
overall BW limits after all CRTC states have been computed. If the check
fails the maximum link bpp for a selected pipe will be reduced and all
the CRTC states will be recomputed until either the overall BW limit
check passes, or further bpp reduction is not possible (because all
pipes/encoders sharing the link BW reached their minimum link bpp).
Atm, the MST encoder allocates twice the required BW for YUV420 format
streams. A follow-up patchset will fix that, add a code comment about
this.
This change prepares for upcoming patches enabling the above BW
management on FDI and MST links.
v2:
- Rename intel_crtc_state::max_link_bpp to max_link_bpp_x16 and
intel_link_bw_limits::max_bpp to max_bpp_x16. (Jani)
v3:
- Add the helper functions in a separate patch. (Ville)
- Add the functions to intel_link_bw.c instead of intel_atomic.c (Ville)
- Return -ENOSPC instead of -EINVAL to userspace in case of a link BW
limit failure.
v4:
- Make intel_atomic_check_config() static.
v5: (Ville)
- Rename intel_link_bw_limits::min_bpp_pipes to min_bpp_reached_pipes
and intel_link_bw_reset_pipe_limit_to_min() to
intel_link_bw_set_min_bpp_for_pipe().
- Rename pipe_bpp to link_bpp in intel_link_bw_reduce_bpp().
- Add FIXME: comment about MST encoder's YUV420 BW allocation and
tracking the link bpp limit accordingly.
v6:
- Move intel_link_bw_compute_pipe_bpp() to intel_fdi.c (Ville)
- WARN_ON(BIT(pipe) & min_bpp_reached_pipes) in
intel_link_bw_set_bpp_limit_for_pipe(). (Ville)
- Rename intel_link_bw_set_min_bpp_for_pipe() to
intel_link_bw_set_bpp_limit_for_pipe() and
intel_link_bw_limits::min_bpp_reached_pipes to
bpp_limit_reached_pipes. (Ville)
- Remove unused header includes.
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230921195159.2646027-10-imre.deak@intel.com
We want to start the DSB execution from the transcoder's undelayed
vblank, so in order to guarantee atomicity with the all the other
mmio register writes we need to evade both vblanks.
Note that currently we don't add any vblank delay, so this is
effectively a nop. But in the future when we start to program
double buffered registers from the DSB we'll need to delay the
pipe's vblank to provide the register programming "window2"
for the DSB.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230606191504.18099-15-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Loading LUTs with the DSB outside of vblank doesn't really
work due to the palette anti-collision logic. Apparently the
DSB register writes don't get stalled like CPU mmio writes
do and instead we end up corrupting the LUT entries. Disabling
the anti-collision logic would allow us to successfully load
the LUT outside of vblank, but presumably that risks the LUT
reads from the scanout (temporarily) getting corrupted data
from the LUT instead.
The anti-collision logic isn't active during vblank so that
is when we can successfully load the LUT with the DSB. That is
what we want to do anyway to avoid tearing.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230606191504.18099-13-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Implement low refresh rate (LRR) where we change the vblank
length by hand as requested, but otherwise keep the timing
generator running in non-VRR mode (ie. fixed refresh rate).
The panel itself must support VRR for this to work, and
only TGL+ has the double buffred TRANS_VTOTAL.VTOTAL that
we need to make the switch properly. The double buffer
latching happens at the start of transcoders undelayed
vblank. The other thing that we change is
TRANS_VBLANK.VBLANK_END but the hardware entirely ignores
that in DP mode. But I decided to keep writing it anyway
just to avoid more special cases in readout/state check.
v2: Document that TRANS_VBLANK.VBLANK_END is ignored by
the hardware
v3: Reconcile with VRR fastset
Adjust update_lrr flag behaviour
Make sure timings stay within VRR range
v4: Fix up update_m_n vs. update_lrr rebase fail (Manasi)
Drop DOUBLE_BUFFER_VACTIVE define as it's not needed (Manasi)
TODO: Hook LRR into the automatic DRRS downclocking stuff?
Cc: Manasi Navare <navaremanasi@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230915103800.14218-1-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
Whenever we change the actual transcoder timings (clock via
seamless M/N, full modeset, (or soon) vtotal via LRR) we
want the timing generator to be in non-VRR during the commit.
Warn if we forgot to turn VRR off prior to vblank evasion.
Cc: Manasi Navare <navaremanasi@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-12-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Make the seamless_m_n flag more like the update_pipe fastset
flag, ie. the flag will only be set if we need to do the seamless
M/N update, and in all other cases the flag is cleared. Also
rename the flag to update_m_n to make it more clear it's similar
to update_pipe.
I believe special casing seamless_m_n like this makes sense
as it also affects eg. vblank evasion. We can potentially avoid
some vblank evasion tricks, simplify some checks, and hopefully
will help with the VRR vs. M/N mess.
Cc: Manasi Navare <navaremanasi@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-6-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
In order to reconcile seamless M/N updates with VRR we'll
need to defer the fastset VRR enable to happen after the
seamless M/N update (which happens during the vblank evade
critical section). So just push the VRR enable to be the last
thing during the update.
This will also affect the vblank evasion as the transcoder
will now still be running with the old VRR state during
the vblank evasion. So just grab the timings always from the
old crtc state during any non-modeset commit, and also grab
the current state of VRR from the active timings (as we disable
VRR before vblank evasion during fastsets).
This also fixes vblank evasion for seamless M/N updates as
we now properly account for the fact that the M/N update
happens after vblank evasion.
Cc: Manasi Navare <navaremanasi@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-5-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Pull the vblank evasion scanline calculations into their own helper
to declutter intel_pipe_update_start() a bit.
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-4-ville.syrjala@linux.intel.com
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
We'll need to also look at the old crtc state in
intel_pipe_update_start() so change the calling convention to
just plumb in the full atomic state instead.
Cc: Manasi Navare <navaremanasi@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-3-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Do the PSR unlock after the vblank evade critcal section is
fully over, not before.
Cc: Manasi Navare <navaremanasi@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-2-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Move the runtime info specific to display into display-specific
structures as has already been done with the constant display info.
v2:
- Rename __runtime to __runtime_defaults for more clarity on the
purpose. (Andrzej)
- Move introduction of DISPLAY_INFO() to previous patch. (Andrzej)
- Drop NO_DISPLAY macro. (Andrzej)
v3:
- Use "{}" instead of "{ 0 }" for empty struct init. (Jani)
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230523195609.73627-4-matthew.d.roper@intel.com
