Move more display specific parts of GPU error logging behind the display
snapshot interface.
With the display register capture reduced to just one register, DERRMR,
there's quite a bit of boilerplate here. However, it's still a nice
abstraction and removes a DISPLAY_VER() usage from core i915. With this
approach, it's also easy to add to xe as needed.
v2: Remove stale comment
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/13206969df04426d290d2863dc574e22ca45193a.1744630147.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Have chv_data_lane_soft_reset() get/put dpio internally, and use a
locked version of it within intel_dpio_phy.c. This drops the dependency
on vlv sideband from g4x_dp.c and g4x_hdmi.c, and makes that a DPIO PHY
implementation detail.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250411102715.613082-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
According to Bspec VRR_CTL_IGN_MAX_SHIFT doesn't exist for MTL and
onwards. On LunarLake and onwards Bit 30 is "Mask Block PkgC" instead. Stop
writing the bit for MeteorLake and onwards
v2: "Ignore Max Shift" bit doesn't exist on MeteorLake either
Bspec: 50508, 68925
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://lore.kernel.org/r/20250409054909.968531-1-jouni.hogander@intel.com
We no longer need i915_drv.h in intel_pch.c, and we no longer need
intel_pch.h universally.
With intel_pch.h being included from intel_display_core.h, it's still
included pretty much everywhere, but there's no need to include it
explicitly from i915_drv.h or xe_device_types.h.
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/68ec70f6880b7af19bc93b9817959299634a555d.1744364975.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Now that intel_pch lives under display, let's begin its
conversion towards struct intel_display.
Move the pch_type to inside intel_display and convert the
callers.
While doing it, sort intel_display_core.h include list
alphabetically.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/8ffe86eb2a02153e3f866a81fb6dc8a3327a0f25.1744364975.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The only usage of the "PCH" infra is to detect which South Display
Engine we should be using. Move it under display so we can convert
all its callers towards intel_display struct later.
No functional or code change.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/041e3dee494aa15c22172360f2bdd9b15e4acb00.1744364975.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Turns out we've added two similar debugfs files. Consolidate on
intel_display_caps as it has more info and a driver independent name.
IGT has already switched over to intel_display_caps in IGT commit
cf837fc17d6c ("lib/dsc: use intel_display_caps instead of
i915_display_capabilities").
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/241c5886cf2e95c694a693bb1b1953f6ae15390e.1744295009.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We are applying the combo PLL frac w/a to all TGL+ platforms, except
RKL. I *think* all RKL machines use a 24 MHz refclk (certainly all
machines in our CI do) and so technically never need the adjustment.
But let's assume the hardware is exactly the same anyway and simplify
the code by applying the w/a to all TGL+ platforms.
v2: Keep the 38.4 MHz check
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250402171720.9350-1-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
DG1 apparently needs the combo PLL fractional divider w/a
with 38.4 MHz refclk as well. This isn't listed in bspec, but
looking at the hsd it looks like it was possibly just missed
due to no one having a DG1 around at the time.
This gives us slightly more accurate clocks on DG1.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250401163752.6412-2-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Going forward, struct intel_display is the main display device data
pointer. Convert the i9xx_wm.h interface to struct intel_display.
With this, we can make intel_wm.c independent of i915_drv.h.
v2: Also remove i915_drv.h, fix commit message
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/3e30634d85c0e0aac9c95f9a2f928131ba400271.1744119460.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Unify the naming of the data and clock lane timing parameters, and
simplify their bounds checks. Drop the debug messages on out of bounds
parameters as excessive.
Clarify the comment while at it.
Cc: William Tseng <william.tseng@intel.com>
Reviewed-by: William Tseng <william.tseng@intel.com>
Tested-by: William Tseng <william.tseng@intel.com>
Link: https://lore.kernel.org/r/d1a75ae7b9d93a0b50976b5de45ba2ca798991ad.1743682608.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The history of why the max of VBT clock and data lane prepare timing
parameter is used for both instead of each individually is
unknown. Separate them to follow what the Windows driver does.
Cc; William Tseng <william.tseng@intel.com>
Reviewed-by: William Tseng <william.tseng@intel.com>
Tested-by: William Tseng <william.tseng@intel.com>
Link: https://lore.kernel.org/r/079a26d0aae79f299aee0397dad2d6519cd55071.1743682608.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
intel_dp::mst.active_links actually indicates the number of MST streams,
not the number of MST links (one MST link carrying one or more MST
streams), rename the field accordingly.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250404150310.1156696-7-imre.deak@intel.com
It's not clear which encoder intel_dp_mst_encoder_active_links() refers
to (primary/stream), but there is also no reason to call the queried
property an encoder property; remove encoder from the name. Also it's
the number of MST streams being queried, vs. the number of MST links
(there is one MST link carrying one or more MST streams), so rename link
to stream as well.
While at it pass intel_dp to the function, which is more logical and
makes it easier to re-use the function later (without the need to get
the digital port pointer).
Also move the function earlier, next to the related ones.
Suggested-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250404150310.1156696-5-imre.deak@intel.com
There doesn't seem to be a reason to assert for a non-negative stream
counter in intel_dp_check_mst_status() in particular, remove it. There
is now an equivalent assert in intel_dp_mst_dec_active_streams().
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250404150310.1156696-4-imre.deak@intel.com
Add helpers to increment/decrement the active MST stream count, instead
of open-coding these.
In mst_stream_pre_enable(), the increment will happen earlier, this is
ok, since nothing depends on the counter between the two points.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250404150310.1156696-3-imre.deak@intel.com
The intel_dp::link_trained flag indicates whether the link is active,
regardless of whether the link training passed or failed. For clarity
rename the flag to 'active'. While at it move the flag under
intel_dp::link.
Suggested-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250404150310.1156696-2-imre.deak@intel.com
If there are no changes to intel_crtc_can_enable_sagv() there
is no need to do all the sagv bw_state recomputation.
The only slight caveat here is hw state takeover where we
initially disable SAGV, and want it to get re-enabled once
we've determined that it's safe to do so. That can now be
achieved by having intel_crtc_can_enable_sagv() reject SAGV
as long as the crtc_state->inherited flag is set. Once the
flag gets cleared (during initial commit for inactive pipes,
during the first userspace commit for active pipes), we
will naturally recompute all the sagv related state.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-14-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Now that all the sagv computation has been moved from the
skl+ watermark code into intel_bw_atomic_check() there is
no point in calling intel_bw_modeset_checks() before the
wm computation. Hide it within intel_bw_atomic_check().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-13-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
The only thing between the current intel_bw_check_sagv_mask() call
site and intel_bw_atomic_check() is skl_wm_add_affected_planes()
which no longer depends on the sagv mask, so we can make life
a lot less confusing by calling intel_bw_check_sagv_mask() from
intel_bw_atomic_check() instead.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-12-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Move the bw_state->pipe_sagv_reject computation into intel_bw.c
where it belongs.
Previously we had a complicated dance between watermarks and
sagv which required this to be computed earlier, but that was
changed in commit 5e8146251f7b ("extract intel_bw_check_sagv_mask()")
which allows the whole thing to be cleaned up quite a bit.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-11-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
I want to use the crtc_state->inherited flag to clean up some
of the early SAGV handling. To make that work nicely I need to
flag even the inactive crtcs as "inherited".
Since we can't expect user space to perform any real commits
on inactive crtcs we'll clear the flag already during
initial_commit().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-8-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Currently intel_bw_calc_min_cdclk() always adds the bw_state
to the atomic state. Not only does it result in potentially
redundant work later, it's also currently causing unwanted cdclk
changes during driver load.
Check if the dbuf bw is actually changing before we decide to
pull in the bw state.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
intel_bw_crtc_min_cdclk() only depends on the pipe data rate,
which we already have stashed in bw_state->data_rate[]. So
stashing the resulting min_cdclk[] as well is redundant. Get
rid of it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
According to the DP spec TPS4 is mandatory for HBR3. We have
however seen some broken eDP sinks that violate this and
declare support for HBR3 without TPS4 support.
At least in the case of the icl Dell XPS 13 7390 this results
in an unstable output.
Reject HBR3 when TPS4 supports is unavailable on the sink.
v2: Leave breadcrumbs in dmesg to avoid head scratching (Jani)
Cc: stable@vger.kernel.org
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250306210740.11886-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
We are seeing timeouts in opening CRC fd when testing on setup where DP
Panel Replay can be enabled. Fix these by checking if CRC is enabled for DP
Panel Replay as well.
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250331090747.2964028-1-jouni.hogander@intel.com
