Age | Commit message (Collapse) | Author |
|
Switch to using the new display->platform.<platform> members for
platform identification in display code.
v2: Split out an unrelated hunk to a separate patch (Rodrigo)
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ed7295a7246bf00d8ae39f78c78dcc842c6939d9.1730144869.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Use struct intel_display where possible.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c925fd0a56ba0a9183b62b7cc0ead0e37264f024.1730144869.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Stop including drm/drm_vblank.h in intel_display_types.h and only
include it where needed.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/0cdb855398ff21e520ef8839b9d00ded40b85fd0.1724689818.git.jani.nikula@intel.com
|
|
When determining various scanlines for DSB use we should take into
account whether VRR is active at the time when the DSB uses said
scanline information. For now all DSB scanline usage occurs prior
to the actual commit, so we only need to care about the state of
VRR at that time.
I've decided to move intel_crtc_scanline_to_hw() in its entirety
to the DSB code as it will also need to know the actual state
of VRR in order to do its job 100% correctly.
TODO: figure out how much of this could be moved to some
more generic place and perhaps be shared with the CPU
vblank evasion code/etc...
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240624191032.27333-8-ville.syrjala@linux.intel.com
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
|
|
Currently we switch from out software idea of a scanline
to the hw's idea of a scanline during the commit phase in
_intel_dsb_commit(). While that is slightly easier due to
fastsets fiddling with the timings, we'll also need to
generate proper hw scanline numbers already when emitting
DSB scanline wait instructions. So this approach won't
do in the future. Switch to hw scanline numbers earlier.
Also intel_dsb_dewake_scanline() itself already makes
some assumptions about VRR that don't take into account
VRR toggling during fastsets, so technically delaying
the sw->hw conversion doesn't even help us.
The other reason for delaying the conversion was that we
are using intel_get_crtc_scanline() during intel_dsb_commit()
which gives us the current sw scanline. But this is pretty
low level stuff anyway so just using raw PIPEDSL reads seems
fine here, and that of course gives us the hw scanline
directly, reducing the need to do so many conversions.
v2: Return the non-hw scanline from intel_dsb_dewake_scanline()
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/20240624191032.27333-5-ville.syrjala@linux.intel.com
|
|
Going forward, struct intel_display shall replace struct
drm_i915_private as the main display device data pointer type. Convert
intel_vblank.[ch] to struct intel_display.
Some stragglers are left behind where needed.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/40430651a45ddd9e350a1fd7938fe4054492f6ea.1724342644.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
When building for xe, we get the context imbalance warning as the actual
locking/unlocking is not compiled:
../drivers/gpu/drm/i915/display/intel_vblank.c:306:13: warning: context imbalance in 'intel_vblank_section_enter' - wrong count at exit
../drivers/gpu/drm/i915/display/intel_vblank.c:314:13: warning: context imbalance in 'intel_vblank_section_exit' - wrong count at exit
Fix by adding separata stubs for xe without __acquires/__releases
annotation.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/111de5bee15f408de65b19ece4b68a7ac66b30cf.1724342644.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
There's a helper for drm->vblank[drm_crtc_index(crtc)], use it.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/78198ade92da1d978f2032c50b3b50e3f8f01701.1724342644.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Calculate the vblank delay in the vblank evasion code correctly
for interlaced modes.
The current code assumes that we won't be using an interlaced mode.
That assumption is actually valid since we've defeatured interlaced
scanout in commit f71c9b7bc35f ("drm/i915/display: Prune Interlace
modes for Display >=12") for DSB capable platforms. However the
feature is still present in the hardware, and if we ever find the
need to re-enable it seems better to calculate the vblank delay
correctly.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240624191032.27333-2-ville.syrjala@linux.intel.com
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
|
|
The DSB code will need to know the hardware's idea of vertical
active, as that is also what defines the start of undelayed
vblank. Introduce a helper that gives us that information,
in line with the other intel_mode_v*() functions.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240611133344.30673-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
Avoid the implicit dev_priv local variable use, and pass dev_priv
explicitly to the PIPE_FRMCOUNT_G4X register macro.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/747124e5eebdb58b06d70a0aae0af4dd7e6b7d86.1717514638.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Avoid the implicit dev_priv local variable use, and pass dev_priv
explicitly to the PIPEFRAMEPIXEL register macro.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/464d4536f90e9d463458cdd315b3ba650e12ada5.1717514638.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Avoid the implicit dev_priv local variable use, and pass dev_priv
explicitly to the PIPEFRAME register macro.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7e6d1a8d3ae2a42efa3a48884e0e37357e0108c1.1717514638.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Avoid the implicit dev_priv local variable use, and pass dev_priv
explicitly to the PIPEDSL register macro.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/53b751f5a883318d44b690284d2e9d5a43fba860.1717514638.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Use intel_color_uses_dsb() instead of open coding it in
intel_vblank_evade_init(). Make the logic around DSB a bit
more isolated from the rest of the code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240531114101.19994-5-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
I want to use intel_crtc_scanline_offset() in
intel_crtc_scanline_to_hw(). Relocate intel_crtc_scanline_offset()
a bit to avoid a forward declaration.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240528185647.7765-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
Currently intel_crtc_scanline_offset() is careful to always
return a positive offset. That is not actually necessary
as long as we take care of negative values when applying the
offset in __intel_get_crtc_scanline().
This simplifies intel_crtc_scanline_offset(), and makes
the scanline_offfset arithmetic more symmetric between
the forward (__intel_get_crtc_scanline()) and reverse
(intel_crtc_scanline_to_hw()) directions.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240528185647.7765-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
We have several copies of code calculating the hardware's
idea of vtotal. Pull that to a helper, similar to
intel_mode_vblank_{start,end}().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240528185647.7765-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
Extract intel_mode_vblank_end() in the same vein as
intel_mode_vblank_start(). While we have only one use
of this it seems nicer to unify the approach.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240528185647.7765-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
Replace a few hand rolled copies of intel_mode_vblank_start() with
the real thing.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240528185647.7765-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
Replace the open coded drm_crtc_vblank_crtc() with the real
thing.
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240408190611.24914-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
intel_vblank.c seems like the appropriate place for the core
vblank evasion code. Move it there.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231213102519.13500-8-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
|
|
The uncore code may not always be available (e.g. when we build the
display code with Xe), so we can't always rely on having the uncore's
spinlock.
To handle this, split the spin_lock/unlock_irqsave/restore() into
spin_lock/unlock() followed by a call to local_irq_save/restore() and
create wrapper functions for locking and unlocking the uncore's
spinlock. In these functions, we have a condition check and only
actually try to lock/unlock the spinlock when I915 is defined, and
thus uncore is available.
This keeps the ifdefs contained in these new functions and all such
logic inside the display code.
Cc: Tvrtko Ursulin <tvrto.ursulin@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231201100032.1367589-1-luciano.coelho@intel.com
|
|
Add a helper to convert our idea of a scanline to the hw's idea
of the same scanline (ie. apply crtc->scanline_offset in reverse).
We'll need this to tell the DSB do stuff on a specific scanline.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230606191504.18099-17-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
|
|
Most places in the vblank code use min() to clamp scanline
counters below vtotal. But we missed one in the gen3/4
pixel counter based codepath.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230404175431.23064-3-ville.syrjala@linux.intel.com
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
|
|
In order to move VRR enable/disable to a place where it's also
applicable to fastsets we need to be prepared to configure
the pipe into non-VRR mode initially, and then later switch
to VRR mode. To that end allow the active timings to be configured
in non-VRR mode temporarily even when the crtc_state says we're
going to be using VRR.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230320203352.19515-5-ville.syrjala@linux.intel.com
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
|
|
Pull the scanline_offset calculation into its own function. Might
have further use for this later with DSB scanline waits.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230310235828.17439-4-ville.syrjala@linux.intel.com
|
|
Move intel_crtc_update_active_timings() into intel_vblank.c
where it more properly belongs.
Also do the s/dev_priv/i915/ modernization rename while at it.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230310235828.17439-3-ville.syrjala@linux.intel.com
|
|
Rename PIPECONF to TRANSCONF to make it clear what it actually
applies to.
While the usual convention is to pick the earliers name I think
in this case it's more clear to use the later name. Especially
as even the register offset is in the wrong range (0x70000 vs.
0x60000) and thus makes it look like this is per-pipe.
There is one place in gvt that's doing something with TRANSCONF
while iterating with for_each_pipe(). So that might not be doing
the right thing for TRANSCODER_EDP, dunno. Not knowing what it
does I left it as is to avoid breakage.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230213225258.2127-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
Add intel_de_read64_2x32() wrapper for the uncore version of the same,
and use it to read the high and low frame registers. Avoid duplicating
code for existing helpers.
The slight functional difference is checking that the entire high
register remains the same across two reads, instead of just the part
we're interested in. This should be of no consequence. (Unless those
bits function as a PRNG.)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/33853549adff82045b95af527e14cfdff5712470.1673873708.git.jani.nikula@intel.com
|
|
Use the intel_de_* functions for display registers.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ecfac5ebddcb46be1ddf2e34e52648fbf9fa4ca6.1673873708.git.jani.nikula@intel.com
|
|
Reduce clutter in intel_display.c by moving the scanline moving/stopped
wait functions to intel_vblank.[ch].
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3613b8c22e5022ebf61ab942e6bc81b717e8f520.1673873708.git.jani.nikula@intel.com
|
|
The vblank/scanline code is fairly isolated in i915_irq.c. Split it out
to new intel_vblank.[ch].
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3e3e9016f5135dccae5110c291ba048567622e7a.1673873708.git.jani.nikula@intel.com
|