Adjust the enabling/disabling steps of the DP audio SDP splitting
according to a recent Bspec update. This moves the enabling to the audio
codec enable sequence after the transcoder is enabled and disables SDP
splitting explicitly during the audio disable sequence.
Bspec requires waiting for a vblank event after the transcoder is
enabled and before SDP splitting is enabled. There is no need for an
explicit wait for this, since after the transcoder is enabled this
vblank event is guaranteed to have happened via a flip done wait (see
intel_atomic_commit_tail() -> drm_atomic_helper_wait_for_flip_done()).
The bspec update is for LNL+ only, but the HW team clarified that this
has been always the intended sequence on all platforms and bspec will be
updated everywhere accordingly.
The way SDP splitting was originally enabled matched the version of
bspec at that time. Adding here the Fixes: line still, since this
change fixes a FIFO underrun on PTL during output enabling when DSC is
enabled.
Bspec: 49283, 68943
Fixes: 8853750dba ("drm/i915: Enable SDP split for DP2.0")
Cc: Vinod Govindapillai <vinod.govindapillai@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250520142219.1688401-1-imre.deak@intel.com
(cherry picked from commit 56764c845a)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Now that INTEL_PCH_TYPE() and HAS_PCH_*() macros are under display, and
accept a struct intel_display pointer, use that instead of struct
drm_i915_private pointer in display code.
This is done naively by running:
$ sed -i 's/\(INTEL_PCH_TYPE\|HAS_PCH_[A-Z0-9_-]*\)([^)]*)/\1(display)/g' \
$(find drivers/gpu/drm/i915/display -name "*.c")
and fixing the fallout, i.e. removing unused local i915 variables and
adding display variables where needed.
v2: Rebase
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Link: https://lore.kernel.org/r/999f4d7b8ed11739b1c5ec8d6408fc39d5e3776b.1744880985.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@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
During modeset enable sequence, program the fixed timings, and turn on the
VRR Timing Generator (VRR TG) for platforms that always use VRR TG.
For this intel_vrr_set_transcoder now always programs fixed timings.
Later if vrr timings are required, vrr_enable() will switch
to the real VRR timings.
For platforms that will always use VRR TG, the VRR_CTL Enable bit is set
and reset in the transcoder enable/disable path.
v2: Update intel_vrr_set_transcoder_timings for fixed_rr.
v3: Update intel_set_transcoder_timings_lrr for fixed_rr. (Ville)
v4: Have separate functions to enable/disable VRR CTL
v5:
-For platforms that do not always have VRRTG on, do write bits other
than enable bit and also use write the TRANS_VRR_PUSH register. (Ville)
-Avoid writing trans_ctl_vrr if !vrr_possible().
v6:
-Disable VRR just before intel_ddi_disable_transcoder_func(). (Ville)
-Correct the sequence of configuring PUSH and VRR Enable/Disable. (Ville)
v7: Reset trans_vrr_ctl to 0 unconditionally in
intel_vrr_transcoder_disable(). (Ville)
v8: Reset trans_vrr_ctl if flipline is not set. (Ville)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250324133248.4071909-9-ankit.k.nautiyal@intel.com
drm/i915 feature pull for v6.15:
Features and functionality:
- Enable DP 128b/132b SST DSC (Jani, Imre)
- Allow DSB to perform commits when VRR is enabled (Ville)
- Compute HDMI PLLs for SNPS/C10 PHYs for rates not in fixed tables (Ankit)
- Allow DSB usage when PSR is enabled on LNL+ (Jouni)
- Enable Panel Replay mode change without full modeset (Jouni)
- Enable async flips with compressed buffers on ICL+ (Ville)
- Support luminance based brightness control via DPCD for eDP (Suraj)
- Enable VRR enable/disable without full modeset (Mitul, Ankit)
- Add debugfs facility for force testing HDCP 1.4 (Suraj)
- Add scaler tracepoints, improve plane tracepoints (Ville)
- Improve DMC wakelock debugging facilities (Gustavo)
- Allow GuC SLPC default strategies on MTL+ for performance (Rodrigo)
- Provide more information on display faults (Ville)
Refactoring and cleanups:
- Continue conversions to struct intel_display (Ville, Jani, Suraj, Imre)
- Joiner and Y plane reorganization (Ville)
- Move HDCP debugfs to intel_hdcp.c (Jani)
- Clean up and unify LSPCON interfaces (Jani)
- Move code out of intel_display.c to reduce its size (Ville)
- Clean up and simplify DDI port enabling/disabling (Imre)
- Make LPT LP a dedicated PCH type, refactor (Jani)
- Simplify DSC range BPG offset calculation (Ankit)
- Scaler cleanups (Ville)
- Remove unused code from GVT (David Alan Gilbert)
- Improve plane debugging (Ville)
- DSB and VRR refactoring (Ville)
Fixes:
- Check if vblank is sufficient for DSC prefill and scaler (Mitul)
- Fix Mesa clear color alignment regression (Ville)
- Add missing TC DP PHY lane stagger delay (Imre)
- Fix DSB + VRR usage for PTL+ (Ville)
- Improve robustness of display VT-d workarounds (Ville)
- Fix platforms for dbuf tracker state service programming (Ravi)
- Fix DMC wakelock support conditions (Gustavo)
- Amend DMC wakelock register ranges (Gustavo)
- Disable the Common Primary Timing Generator (CMTG) (Gustavo)
- Enable C20 PHY SSC (Suraj)
- Add workaround for DKL PHY DP mode write (Nemesa)
- Fix build warnings on clamp() usage (Guenter Roeck, Ankit)
- Fix error handling while adding a connector (Imre)
- Avoid full modeset at probe on vblank delay mismatches (Ville)
- Fix encoder HDMI check for HDCP line rekeying (Suraj)
- Fix HDCP repeater authentication during topology change (Suraj)
- Handle display PHY power state reset for power savings (Mika)
- Fix typos all over the place (Nitin)
- Update HDMI TMDS C20 parameters for various platforms (Dnyaneshwar)
- Guarantee a minimum hblank time for 128b/132b and 8b/10b MST (Arun, Imre)
- Do not hardcode LSPCON settle timeout (Giedrius Statkevičius)
Xe driver changes:
- Re-use display vmas when possible (Maarten)
- Remove double pageflip (Maarten)
- Enable DP tunneling (Imre)
- Separate i915 and xe tracepoints (Ville)
DRM core changes:
- Increase DPCD eDP display control CAP size to 5 bytes (Suraj)
- Add DPCD eDP version 1.5 definition (Suraj)
- Add timeout parameter to drm_lspcon_set_mode() (Giedrius Statkevičius)
Merges:
- Backmerge drm-next (Jani)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/87h64j7b7n.fsf@intel.com
The encoder HW/SW state verification should use a SW state which stays
unchanged while the encoder/output is active. The intel_dp::is_mst flag
used during state computation to choose between the DP SST/MST modes can
change while the output is active, if the sink gets disconnected or the
MST topology is removed for another reason. A subsequent state
verification using intel_dp::is_mst leads then to a mismatch if the
output is disabled/re-enabled without recomputing its state.
Use the encoder's active MST link count instead, which will be always
non-zero for an active MST output and will be zero for SST.
Fixes: 35d2e4b756 ("drm/i915/ddi: start distinguishing 128b/132b SST and MST at state readout")
Fixes: 40d489fac0 ("drm/i915/ddi: handle 128b/132b SST in intel_ddi_read_func_ctl()")
Cc: 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://patchwork.freedesktop.org/patch/msgid/20250224093242.1859583-1-imre.deak@intel.com
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: 79a6734cd5 ("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>
(cherry picked from commit 2ed653c7b8)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
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: 79a6734cd5 ("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>
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().
v2: s/mtl_ddi_disable_d2d_link/mtl_ddi_disable_d2d (Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-9-imre.deak@intel.com
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)
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-8-imre.deak@intel.com
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.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-7-imre.deak@intel.com
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 2885d283cc ("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)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-6-imre.deak@intel.com
Currently we are configuring Panel Replay on sink when it get's
enabled. This means we need to do full modeset when enabling Panel
Replay. This is required as DP specification is saying sink Panel Replay
needs to be configured before link training. Avoid full modeset by enabling
Panel Replay on sink always when it's supported by the sink and the
source.
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250109103532.2093356-3-jouni.hogander@intel.com
We'll want to distinguish 128b/132b SST and MST modes at state
readout. There's a catch, though. From the hardware perspective,
128b/132b SST and MST programming are pretty much the same. And we can't
really ask the sink at this point.
If we have more than one transcoder in 128b/132b mode associated with
the port, we can safely assume it's MST. But for MST with only a single
stream enabled, we are pretty much out of luck. Let's fall back to
looking at the software state, i.e. intel_dp->is_mst. It should be fine
for the state checker, but for hardware takeover at probe, we'll have to
trust the GOP has only enabled SST.
TODO: Not sure how this *or* our current code handles 128b/132b enabled
by GOP.
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/119a773a0d4d74ad204435e462f8d12cb0ea4128.1735912293.git.jani.nikula@intel.com
Write the payload allocation table for 128b/132b SST. Use VCPID 1 and
start from slot 0, with dp_m_n.tu slots.
This is preparation for enabling 128b/132b SST. This path is not
reachable yet. Indeed, we don't yet compute TU for 128b/132b SST.
v2: Handle drm_dp_dpcd_write_payload() failures (Imre)
v3: Include drm_dp_helper.h (kernel test robot)
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250107095414.1244286-1-jani.nikula@intel.com
