Imre Deak [Mon, 17 Feb 2025 22:38:28 +0000 (00:38 +0200)]
drm/i915/dp: Fix disabling the transcoder function in 128b/132b mode
During disabling the transcoder in DP 128b/132b mode (both in case of an
MST master transcoder and in case of SST) the transcoder function must
be first disabled without changing any other field in the register (in
particular leaving the DDI port and mode select fields unchanged) and
clearing the DDI port and mode select fields separately, later during
the disabling sequences. Fix the sequence accordingly.
Bspec: 54128, 65448, 68849 Cc: Jani Nikula <jani.nikula@intel.com> Fixes: 79a6734cd56e ("drm/i915/ddi: disable trancoder port select for 128b/132b SST") Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250217223828.1166093-3-imre.deak@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Imre Deak [Mon, 17 Feb 2025 22:38:27 +0000 (00:38 +0200)]
drm/i915/dp: Fix error handling during 128b/132b link training
At the end of a 128b/132b link training sequence, the HW expects the
transcoder training pattern to be set to TPS2 and from that to normal
mode (disabling the training pattern). Transitioning from TPS1 directly
to normal mode leaves the transcoder in a stuck state, resulting in
page-flip timeouts later in the modeset sequence.
Atm, in case of a failure during link training, the transcoder may be
still set to output the TPS1 pattern. Later the transcoder is then set
from TPS1 directly to normal mode in intel_dp_stop_link_train(), leading
to modeset failures later as described above. Fix this by setting the
training patter to TPS2, if the link training failed at any point.
The clue in the specification about the above HW behavior is the
explicit mention that TPS2 must be set after the link training sequence
(and there isn't a similar requirement specified for the 8b/10b link
training), see the Bspec links below.
v2: Add bspec aspect/link to the commit log. (Jani)
Jouni Högander [Thu, 13 Feb 2025 11:16:28 +0000 (13:16 +0200)]
drm/i915/psr: Fix drm_WARN_ON in intel_psr_disable
Currently intel_psr_disable is dumping out warning if PSR is not
supported. On monitor supporting only Panel Replay we are seeing this
warning. Fix this by checking Panel Replay support as well.
Mika Kahola [Tue, 18 Feb 2025 10:00:19 +0000 (12:00 +0200)]
drm/i915/display: Allow display PHYs to reset power state
The dedicated display PHYs reset to a power state that blocks S0ix,
increasing idle system power. After a system reset (cold boot,
S3/4/5, warm reset) if a dedicated PHY is not being brought up
shortly, use these steps to move the PHY to the lowest power state
to save power.
1. Follow the PLL Enable Sequence, using any valid frequency such
as DP 1.62 GHz. This brings lanes out of reset and enables the
PLL to allow powerdown to be moved to the Disable state.
2. Follow PLL Disable Sequence. This moves powerdown to the Disable
state and disables the PLL.
v2: Rename WA function to more descriptive (Jani)
For PTL, only port A needs this wa
Add helpers to check presence of C10 phy and pll enabling (Imre)
v3: Rename wa function (Imre)
Check return value of C10 pll tables readout (Imre)
Use PLL request to check pll enabling (Imre)
v4: Move intel_cx0_pll_is_enabled() right after
intel_cx0_pll_disable() (Imre)
Add drm_WARN_ON() if C10 state cannot be calculated from
the tables (Imre)
v5: Add debug message on PLL enabling (Imre)
Add check for intel_encoder_is_dig_port() (Imre)
Mika Kahola [Tue, 18 Feb 2025 10:00:18 +0000 (12:00 +0200)]
drm/i915/display: Drop crtc_state from C10/C20 pll programming
For PLL programming for C10 and C20 we don't need to
carry crtc_state but instead use only necessary parts
of the crtc_state i.e. pll_state.
This change is needed to PTL wa 14023648281 where we would
need to otherwise pass an artificial crtc_state with majority
of the struct members initialized as NULL.
v2: Use err instead of val for error handling (Imre)
Unify parameter order (Imre)
v3: Fix misplaced port_clock, and is_dp in
intel_c20_pll_program() call (Imre)
Ville Syrjälä [Mon, 17 Feb 2025 07:00:47 +0000 (09:00 +0200)]
drm/i915: Hook up display fault interrupts for VLV/CHV
Hook up the display fault irq handlers for VLV/CHV.
Unfortunately the actual hardware doesn't agree with the
spec on how DPINVGTT should behave. The docs claim that
the status bits can be cleared by writing '1' to them,
but in reality there doesn't seem to be any way to clear
them. So we must disable and ignore any fault we've already
seen in the past. The entire register does reset when
the display power well goes down, so we can just always
re-enable all the bits in irq postinstall without having
to track the state beyond that.
v2: Use intel_display instead of dev_priv
Move xe gen2_error_{init,reset}() out
Ville Syrjälä [Mon, 17 Feb 2025 07:00:46 +0000 (09:00 +0200)]
drm/i915: Un-invert {i9xx,i965}_error_mask()
Make life a bit more straightforward by removing the bitwise
not from {i9xx,i965}_error_mask() and instead do it when feeding
the value to gen2_error_init(). Make life a bit easier I think.
Ville Syrjälä [Mon, 17 Feb 2025 07:00:45 +0000 (09:00 +0200)]
drm/i915: Introduce i915_error_regs
Introduce i915_error_regs as the EIR/EMR counterpart
to the IIR/IMR/IER i915_irq_regs, and update the irq
reset/postingstall to utilize them accordingly.
Ville Syrjälä [Mon, 17 Feb 2025 07:00:42 +0000 (09:00 +0200)]
drm/i915: Pimp display fault reporting
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.
Ville Syrjälä [Mon, 17 Feb 2025 07:00:41 +0000 (09:00 +0200)]
drm/i915: Introduce a minimal plane error state
I want to capture a little bit more information about the state
of the plane upon faults. To that end introduce a small plane error
state struct and provide per-plane vfuncs to read it out.
For now we just stick the CTL, SURF, and SURFLIVE (if available)
registers contents in there.
Ville Syrjälä [Mon, 17 Feb 2025 07:00:40 +0000 (09:00 +0200)]
drm/i915: Add missing else to the if ladder in missing else
The if ladder in gen8_de_pipe_fault_mask() was missing one
else, add it. Doesn't actually matter since each if branch
just returns directly. But the code is less confusing when
you always do things the same way.
Ville Syrjälä [Thu, 13 Feb 2025 15:02:19 +0000 (17:02 +0200)]
drm/i915: Relocate some other plane fb related stuff into intel_fb.c
Move intel_fb_xy_to_linear() and intel_add_fb_offsets()
These are technially sitting somewhere between plane vs. fb code,
but we do have a bunch of code like that in intel_fb.c anyway.
Might need to think about splitting intel_fb.c into pure fb vs.
plane->fb related stuff somehow, but dunno if that's even feasible.
Move intel_{rotation,remapped}_info_size() into intel_fb.c as
that seems a slightly better place than intel_display.c. I suppose
these should live somewhere outside the display code as they are
also used by the gem code.
Ville Syrjälä [Thu, 13 Feb 2025 15:02:17 +0000 (17:02 +0200)]
drm/i915: Relocate intel_plane_uses_fence()
Relocate intel_plane_uses_fence() into intel_fb.c. Not sure
that's the best place, but since this is mostly about the
fb and vma I can't think of anything truly better right now.
Ville Syrjälä [Thu, 13 Feb 2025 15:02:15 +0000 (17:02 +0200)]
drm/i915: Relocate vlv_wait_port_ready()
While vlv_wait_port_ready() doens't directly talk to the VLV/CHV
DPIO PHY, the signals it's looking for do come from the PHY. So
it seems appropriate to relocate it into intel_dpio_phy.c.
Ville Syrjälä [Thu, 13 Feb 2025 15:02:14 +0000 (17:02 +0200)]
drm/i915: Move intel_plane_destroy() into intel_atomic_plane.c
intel_atomic_plane.c (should rename it really) has become our
standard place for generic plane code. Move intel_plane_destroy()
there so it doesn't clutter intel_display.c.
Since we have all the necessary bits in intel_connector.c might
as well always initialize the modeset_retry_work for every connector.
Avoids yet another init function you have to remember to call.
Ville Syrjälä [Thu, 13 Feb 2025 15:02:09 +0000 (17:02 +0200)]
drm/i915: Move modeset_retry stuff into intel_connector.c
Most of the modeset retry stuff looks to be entirely generic,
and so there doesn't seem to any reason to keep it in intel_dp.c.
Move the generic bits into intel_connector.c.
Ville Syrjälä [Wed, 12 Feb 2025 16:43:28 +0000 (18:43 +0200)]
drm/i915: Rename the variables in icl_check_nv12_planes()
All the this generic 'plane' vs 'linked' stuff is hard to
follow. Rename the variables to use the y_plane vs. uv_plane
terminology to make it clear which is which.
Ville Syrjälä [Wed, 12 Feb 2025 16:43:23 +0000 (18:43 +0200)]
drm/i915: Rework joiner and Y plane dependency handling
The current code tries to handle joiner vs. Y planes completely
independently. That does not really work since each pipe selects
its Y planes completely independently, and any plane pulled into
the state by one of the secondary pipes needs to have the plane
on the primary pipe also included in the state (for the uapi
state copy). The current code sometimes forgets to pull in planes
that we need, leading to weird things like the Y<->UV plane link
only getting torn down from one side but not the other.
Remedy the situation by pulling in the exact same set planes
on all the joined pipes. To calculate the set we simply
look through each joined crtc and any plane in the state gets
added to the set. However due to the way the Y plane selection
works we may not be able to determine the set in one go. One
plane on one pipe may pull in a Y plane, which may have to pull
in another plane because it's not acting in the same role on
another pipe, etc. The simple approach taken here is to keep
looping and adding planes to the set until it stops growing.
I suppose if we tracked more of this Y plane stuff in the
crtc state rather than the plane state we might be able to
do it in one go. But this works, and it's not going to loop
for long anyway since we only have so many pipes and Y planes
to consider.
Ville Syrjälä [Wed, 12 Feb 2025 16:43:21 +0000 (18:43 +0200)]
drm/i915: Make sure all planes in use by the joiner have their crtc included
Any active plane needs to have its crtc included in the atomic
state. For planes enabled via uapi that is all handler in the core.
But when we use a plane for joiner the uapi code things the plane
is disabled and therefore doesn't have a crtc. So we need to pull
those in by hand. We do it first thing in
intel_joiner_add_affected_crtcs() so that any newly added crtc will
subsequently pull in all of its joined crtcs as well.
The symptoms from failing to do this are:
- duct tape in the form of commit 1d5b09f8daf8 ("drm/i915: Fix NULL
ptr deref by checking new_crtc_state")
- the plane's hw state will get overwritten by the disabled
uapi state if it can't find the uapi counterpart plane in
the atomic state from where it should copy the correct state
Imre Deak [Fri, 14 Feb 2025 14:19:59 +0000 (16:19 +0200)]
drm/i915/ddi: Unify the platform specific functions disabling a port
The functions disabling a port for MTL+ and earlier platforms only
differ by an extra step on MTL+ (to disable the D2D link) and the point
at which the port's idle state is waited for. Combine the two functions
accounting for the above differences, removing the duplication.
Imre Deak [Fri, 14 Feb 2025 14:19:58 +0000 (16:19 +0200)]
drm/i915/ddi: Move platform checks within mtl_ddi_enable/disable_d2d_link()
The prefix of the mtl_ddi_enable_d2d() / mtl_ddi_disable_d2d_link()
names show already what are the relevant platforms, so the corresponding
platform check is a detail that can be hidden in the functions, do so.
While at it rename mtl_ddi_disable_d2d_link() to mtl_ddi_disable_d2d()
for symmetry with mtl_ddi_enable_d2d().
Imre Deak [Fri, 14 Feb 2025 14:19:57 +0000 (16:19 +0200)]
drm/i915/ddi: Simplify waiting for a port to get active/idle via DDI_BUF_CTL
When waiting for a port to get active/idle there is no point in the
complexity of specifying an exact timeout and for that the suitable wait
API instead of just using the maximum timeout. The sequence in
particular is not performance critical at all either and due to
scheduling it's not guaranteed anyhow how long the wait will last at the
given timescale. In the usual case where the wait succeeds the actual
time waited does not change with the increased timeout.
Simplify things accordingly, describing the bspec platform specific
timeouts in code comments.
v2: Clarify the rationale in the commit log. (Jani)
Imre Deak [Fri, 14 Feb 2025 14:19:56 +0000 (16:19 +0200)]
drm/i915/ddi: Simplify the port disabling via DDI_BUF_CTL
A port can be disabled only via a modeset (or during HW state
sanitization) when the port is enabled. Thus it's not required to check
the port's enabled state before disabling it. In any case if the port
happened to be disabled, the following disabling would be just a nop and
waiting for the buffer's idle state should succeed. Simplify the
disabling sequence accordingly.
Imre Deak [Fri, 14 Feb 2025 14:19:55 +0000 (16:19 +0200)]
drm/i915/ddi: Simplify the port enabling via DDI_BUF_CTL
In the past intel_digital_port::dp.prepare_link_retrain() could be
called directly (vs. from a modeset) to retrain an enabled link. In that
case the port had to be first disabled and then re-enabled. That changed
with commit 2885d283cce5 ("drm/i915/dp: Retrain SST links via a modeset
commit"), after which the only way prepare_link_retrain() can be called
is from a modeset during link training when the port is still disabled.
Simplify things accordingly, assuming the disabled port state.
v2: Don't use drm_i915_private in intel_ddi_prepare_link_retrain(). (Jani)
Imre Deak [Fri, 14 Feb 2025 14:19:53 +0000 (16:19 +0200)]
drm/i915/ddi: Make all the PORT_WIDTH macros work the same way
Make the PORT_WIDTH macro of the XELPDP_PORT_CTL1 register work the same
way as those used for the DDI_BUF_CTL and the TRANS_DDI_FUNC_CTL
registers: accept a width parameter and convert it to the given
register's encoding.
Imre Deak [Fri, 14 Feb 2025 14:19:51 +0000 (16:19 +0200)]
drm/i915/dsi: Use TRANS_DDI_FUNC_CTL's own port width macro
The format of the port width field in the DDI_BUF_CTL and the
TRANS_DDI_FUNC_CTL registers are different starting with MTL, where the
x3 lane mode for HDMI FRL has a different encoding in the two registers.
To account for this use the TRANS_DDI_FUNC_CTL's own port width macro.
Jouni Högander [Thu, 13 Feb 2025 06:48:03 +0000 (08:48 +0200)]
drm/i915/display: Ensure we have "Frame Change" event in DSB commit
We may have commit which doesn't have any non-arming plane register
writes. In that case there aren't "Frame Change" event before DSB vblank
evasion which hangs as PIPEDSL register is reading as 0 when PSR state is
SRDENT(PSR1) or DEEP_SLEEP(PSR2). Handle this by ensuring "Frame Change"
event at the begin of DSB commit if using PSR/PR.
v3: dsb_commit as a first parameter
v2: use intel_psr_trigger_frame_change_event
Jouni Högander [Thu, 13 Feb 2025 06:48:01 +0000 (08:48 +0200)]
drm/i915/display: Evade scanline 0 as well if PSR1 or PSR2 is enabled
PIPEDSL is reading as 0 when in SRDENT(PSR1) or DEEP_SLEEP(PSR2). On
wake-up scanline counting starts from vblank_start - 1. We don't know if
wake-up is already ongoing when evasion starts. In worst case PIPEDSL could
start reading valid value right after checking the scanline. In this
scenario we wouldn't have enough time to write all registers. To tackle
this evade scanline 0 as well. As a drawback we have 1 frame delay in flip
when waking up.
v2:
- use intel_dsb_emit_wait_dsl
- add evasion of scanline 0 also for Panel Replay
Jouni Högander [Thu, 13 Feb 2025 06:48:00 +0000 (08:48 +0200)]
drm/i915/psr: Remove DSB_SKIP_WAITS_EN chicken bit
We have different approach on how flip is considered being complete. We are
waiting for vblank on DSB and generate interrupt when it happens and this
interrupt is considered as indication of completion -> we definitely do not
want to skip vblank wait.
Also not skipping scanline wait shouldn't cause any problems if we are in
DEEP_SLEEP PIPEDSL register is returning 0 -> evasion does nothing and if
we are not in DEEP_SLEEP evasion works same way as without PSR.
v2: add comment explaining why we are not setting DSB_SKIP_WAITS_EN
Jouni Högander [Thu, 13 Feb 2025 06:47:59 +0000 (08:47 +0200)]
drm/i915/display: Warn on use_dsb in non-dsb pipe update functions
Add drm_WARN_ON(use_dsb) into commit_pipe_{pre,post}_planes() and
intel_pipe_update_{start,end}() as they are not supposed to get called on
non-dsb updates.
Jouni Högander [Thu, 13 Feb 2025 06:47:57 +0000 (08:47 +0200)]
drm/i915/psr: Allow writing PSR2_MAN_TRK_CTL using DSB
Allow writing PSR2_MAN_TRK_CTL using DSB by using intel_de_write_dsb. Do
not check intel_dp->psr.lock being held when using DSB. This assertion
doesn't make sense as in case of using DSB the actual write happens later
and we are not taking intel_dp->psr.lock mutex over dsb commit.
Jouni Högander [Thu, 13 Feb 2025 06:47:56 +0000 (08:47 +0200)]
drm/i915/psr: Use SFF_CTL on invalidate/flush for LunarLake onwards
In LunarLake we have SFF_CTL register which contains SFF bit ored with
respective SFF bit in PSR2_MAN_TRK_CTL register. Use this register instead
of the bit in PSR2_MAN_TRK_CTL on frontbuffer tracking callbacks. This
helps us avoiding taking psr mutex when performing atomic commit.
We don't need to set the CFF bit as selective update configuration in
PSR2_MAN_TRL_CTL is not overwritten anymore. I.e. we have valid
configuration in PSR2_MAN_TRK_CTL and in plane SEL_FETCH_* registers when
SFF bit gets cleared by the HW in case something triggers "frame change"
event after SFF bit is cleared.
Jouni Högander [Thu, 13 Feb 2025 06:47:53 +0000 (08:47 +0200)]
drm/i915/psr: Rename psr_force_hw_tracking_exit as intel_psr_force_update
psr_force_hw_tracking_exit is misleading name as it is used for PSR1, PSR2
HW tracking and PSR2 selective fetch. Due to this rename it as
intel_psr_force_update.
Jouni Högander [Thu, 13 Feb 2025 06:47:52 +0000 (08:47 +0200)]
drm/i915/psr: Use PSR2_MAN_TRK_CTL CFF bit only to send full update
We are preparing for a change where only frontbuffer flush will use
single full frame bit of a new register (SFF_CTL) available on LunarLake
onwards.
It shouldn't be necessary to have SFF bit set if CFF bit is set in
PSR2_MAN_TRK_CTL -> removing setting it on all platforms as there is not
reason to have it different on older platforms.
Jani Nikula [Wed, 12 Feb 2025 16:36:43 +0000 (18:36 +0200)]
drm/i915/display: convert i915_pipestat_enable_mask() to struct intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert i915_pipestat_enable_mask() to struct intel_display,
allowing further conversions elsewhere.
Jani Nikula [Wed, 12 Feb 2025 16:36:42 +0000 (18:36 +0200)]
drm/i915/display: convert intel_fifo_underrun.[ch] to struct intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_fifo_underrun.[ch] to
struct intel_display.
Jani Nikula [Wed, 12 Feb 2025 16:36:41 +0000 (18:36 +0200)]
drm/i915/combo-phy: convert intel_combo_phy.[ch] to struct intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_combo_phy.[ch] to struct
intel_display, along with intel_phy_is_combo() in intel_display.c.
Drive-by convert some drm_dbg() to drm_dbg_kms() while at it.
Jani Nikula [Wed, 12 Feb 2025 16:36:39 +0000 (18:36 +0200)]
drm/i915/display: convert intel_mode_valid_max_plane_size() to intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert the intel_mode_valid_max_plane_size() helper to struct
intel_display, allowing further conversions elsewhere.
Jani Nikula [Wed, 12 Feb 2025 16:36:38 +0000 (18:36 +0200)]
drm/i915/display: convert intel_cpu_transcoder_mode_valid() to intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert the intel_cpu_transcoder_mode_valid()() helper to
struct intel_display, allowing further conversions elsewhere.
Jani Nikula [Wed, 12 Feb 2025 16:36:36 +0000 (18:36 +0200)]
drm/i915/display: convert intel_set_{cpu,pch}_fifo_underrun_reporting() to intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert intel_set_cpu_fifo_underrun_reporting() and
intel_set_pch_fifo_underrun_reporting() to struct intel_display, along
with some of the call chains from there.
Jani Nikula [Wed, 12 Feb 2025 16:36:34 +0000 (18:36 +0200)]
drm/i915/display: convert assert_port_valid() to struct intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert the assert_port_valid() helper to struct intel_display,
allowing further conversions elsewhere.
Jani Nikula [Wed, 12 Feb 2025 16:36:33 +0000 (18:36 +0200)]
drm/i915/display: convert assert_transcoder*() to struct intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert the assert_transcoder*() helpers to struct
intel_display, allowing further conversions elsewhere.
Do a few small opportunistic conversions right away.
Ville Syrjälä [Mon, 10 Feb 2025 16:07:11 +0000 (18:07 +0200)]
drm/i915/vrr: Check that the push send bit is clear after delayed vblank
Since we don't do mailbox updates the push send bit
should alwyas clear by the time the delay vblank fires
and the flip completes. Check for that to make sure we
haven't screwed up the sequencing/vblank evasion/etc.
On the DSB path we should be able to guarantee this
since we don't have to deal with any scheduler latencies
and whatnot. I suppose unexpected DMA/memory latencies
might be the only thing that might trip us up here.
For the MMIO path we do always have a non-zero chance
that vblank evasion fails (since we can't really guarantee
anything about the scheduling behaviour). That could trip
up this check, but that seems fine since we already print
errors for other types of vblank evasion failures.
Should the CPU vblank evasion actually fail, then the push
send bit can still be set when the next commit happens. But
both the DSB and MMIO paths should handle that situation
gracefully.
v2: Only check once instead of polling for two scanlines
since we should now be guaranteed to be past the
delayed vblank.
Also check in the MMIO path for good measure
v3: Skip the push send check when VRR is disabled.
With joiner the secondary pipe's DSBs doen't have access
to the transcoder registers, and so doing this check
there triggers a reponse timeout error on the DSB. VRR
is not currently allowed when using joiner, so this will
prevent the bogus register access.
Ville Syrjälä [Fri, 7 Feb 2025 22:31:57 +0000 (00:31 +0200)]
drm/i915/vrr: Reorder the DSB "wait for safe window" vs. TRANS_PUSH
Currently we trigger the push send first, then follow it with
a "wait for safe window". That approach no longer works on
PTL+ because triggering the push send immediately ends the safe
window. On prior hardware the safe window extended past the
push being sent (presumably all the way to the pipe's delayed
vblank).
In order to deal with the new hardware behaviour we must reverse
the order of these two operations: first wait for safe window,
then trigger the push.
The only slight danger with this approach is that if we mess up
the vblank evasion around the vmax decision boundary the push
might get postponed until after the next frame's vactive. But
assuming we don't mess up the vblank evasion this approach is
completely safe.
As a slight bonus we can perform the push after we've done the
LUT writes as well, meaning we no longer have to worry about
extending the vblank delay to provide enough time for LUT
programming. Instead we will now depend on the vblank evasion
at vmax decision boundary to guarantee this.
However vblank delay (or framestart delay) is still the only
way to provide extra time for the LUT programming in the
non-VRR use cases. Let's assume we don't need anything extra
for now, but eventually we should come up with some proper
estimates on how long the LUT programming can take and
configure the vblank delay accordingly for the non-VRR use
cases.
Ville Syrjälä [Fri, 7 Feb 2025 22:31:55 +0000 (00:31 +0200)]
drm/i915/dsb: Compute use_dsb earlier
Skip all the commit completion interrupt stuff on the
chained DSB when we don't take the full DSB path (ie. when
the plane/pipe programming is done via MMIO). The commit
completion will be done via the CPU side vblank interrupt.
Currently this is just a redundant interrupt, so not a big
deal. But in the future we'll be moving the TRANS_PUSH write
into the chained DSB as well, and that we definitely don't
want to do when it's also being done by the CPU from
intel_pipe_update_end().
Ville Syrjälä [Fri, 7 Feb 2025 22:31:54 +0000 (00:31 +0200)]
drm/i915/vrr: Account for TRANS_PUSH delay
When we send a push during vblank the TRANS_PUSH write happens
at some point during a scanline, and the hardware picks it up
on the next scanline. Thus there is up to one extra scanline
of delay between the TRANS_PUSH write and the delayed vblank
triggering. Account for that during intel_dsb_wait_vblank_delay()
so that we are guaranteed to be past the delayed vblank before
we trigger the completion interrupt for the commit.
Ville Syrjälä [Fri, 7 Feb 2025 22:31:53 +0000 (00:31 +0200)]
drm/i915/vrr: Don't send push for legacy cursor updates
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.
Ville Syrjälä [Fri, 7 Feb 2025 22:31:52 +0000 (00:31 +0200)]
drm/i915/dsb: Move the +1 usec adjustment into dsb_wait_usec()
The "wait usec" DSB command doesn't quite seem to able to
guarantee that it always waits at least the specified
amount of usecs. Some of that could be just because it
supposedly just does some kind of dumb timestamp comparison
internally. But I also see cases where two hardware timestamps
sampled on each side of the "wait usec" command come out one
less than expected. So it looks like we always need at least a
+1 to guarantee that we never wait less than specified. Always
apply that adjustment in dsb_wait_usec().
Jani Nikula [Fri, 7 Feb 2025 10:17:37 +0000 (12:17 +0200)]
drm/i915/pch: Hide PCH device IDs
Only the PCH identification code needs the PCH device IDs, as all the
PCH checks are now based on PCH type. Hide the PCH device IDs inside
intel_pch.c. Remove the unused INTEL_PCH_ID() macro while at it.
Jani Nikula [Fri, 7 Feb 2025 10:17:36 +0000 (12:17 +0200)]
drm/i915/pch: Make LPT LP a dedicated PCH type
Add PCH type PCH_LPT_LP and rename PCH_LPT to PCH_LPT_H for
consistency. Keep the existing HAS_PCH_LPT*() macros, but express them
in terms of the PCH types instead of looking at the device IDs
directly. This makes the PCH checks independent of the PCH device IDs.
Suraj Kandpal [Wed, 12 Feb 2025 07:45:41 +0000 (13:15 +0530)]
drm/i915/dpll: Accept intel_display as argument for shared_dpll_init
Use intel_display as an argument for intel_shared_dpll_init() and
replace drm_i915_private in function wherever possible.
While at it prefer using display->platform.xx over IS_PLATFORM.
Initialize dpio_phy and dpio_channel since with IS_GEMINILAKE()
and IS_BROXTON() compiler knows it will return false for xe but
since display->platform.xx is a runtime check which means the
compiler sees a potential path where uninitialized variables
could be accessed and raises a warning.
--v2
-Amend commit message to explain why some variables were
initialized [Jani]
Suraj Kandpal [Wed, 12 Feb 2025 07:45:38 +0000 (13:15 +0530)]
drm/i915/dpll: Use intel_display possible in shared_dpll_mgr hooks
We use intel_display for function hooks of shared_dpll_mgr and
any function that gets called when we use for_each_shared_dpll.
This also contains some opportunistic display->platform.xx changes
all to reductate the use of drm_i915_private.
Suraj Kandpal [Wed, 12 Feb 2025 07:45:37 +0000 (13:15 +0530)]
drm/i915/dpll: Use intel_display for dpll dump and compare hw state
Let's use intel_display for dpll dump and compare hw state. This also
helps elimanate drm_i915_private dependency from i915_shared_dplls_info
in intel_display_debugfs.c
Suraj Kandpal [Wed, 12 Feb 2025 07:45:36 +0000 (13:15 +0530)]
drm/i915/dpll: Change param to intel_display in for_each_shared_dpll
Change the argument of for_each_shared_dpll to take intel_display which
helps move as an ongoing effort to get rid off the dependency on
drm_i915_private. Some opportunistic changes in intel_pch_refclk done
too.
Suraj Kandpal [Wed, 12 Feb 2025 07:45:35 +0000 (13:15 +0530)]
drm/i915: Use intel_display wherever possible
Use struct intel_display wherever possible in intel_display_debug_fs.c
to reduce the use of drm_i915_private.
While at it do the opportunistic display->platform.xx replacement.
--v2
-Rebase
--v3
-Don't use inline to_intel_display [Jani]
-Don't use display debug fs as subject prefix [Jani]
Convert the remaining intel_display_power.h interfaces to
take struct intel_display instead of struct drm_i915_private.
intel_display_power.c still has some internal uses due to
i915->runtime_pm.
Looks like I missed one of myriad CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n
special cases when converting the intel_display_power_{get,put}()
code to use struct intel_display. Only noticed after the fact
when building a EXPERT=n kernel :/
Ville Syrjälä [Thu, 6 Feb 2025 18:55:33 +0000 (20:55 +0200)]
drm/i915: Pimp plane debugs
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.
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.
projects / thirdparty / linux.git / log
