As we plan to add audio BW calculation in i915,
intel_audio_compute_config() would need the final output_format
and pipe_bpp to correctly determine audio bandwidth constraints.
Move the intel_audio_compute_config() call to after
intel_hdmi_compute_formats() returns, ensuring the audio
configuration is computed with the final parameters.
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260901103639.617757-2-chaitanya.kumar.borah@intel.com
psr_get_status_and_error_status() selects the DPCD offset to read the error
status from based on whether Panel Replay is enabled:
offset = intel_dp->psr.panel_replay_enabled ?
DP_PANEL_REPLAY_ERROR_STATUS : DP_PSR_ERROR_STATUS;
but intel_psr_short_pulse() acknowledges it unconditionally to the PSR
register. Under Panel Replay the error is therefore read from
DP_PANEL_REPLAY_ERROR_STATUS (0x2020) and the acknowledgment written to
DP_PSR_ERROR_STATUS (0x2006). DP_PANEL_REPLAY_ERROR_STATUS is never written
anywhere in the tree; it appears only in the read above and in its own
The sink's Panel Replay error latch can consequently never be cleared. Once
it latches, every subsequent short pulse re-reads the same errors, so PSR
is disabled with sink_not_reliable set permanently, and until a short pulse
arrives the driver keeps Panel Replay enabled while the sink is reporting
errors it cannot see.
Observed on a Dell XPS 16 DA16260 (Panther Lake, Arc B390, display version
30.00) with the eDP Panel Replay quirk from commit cb8d155b08
("drm/i915/psr: Disable Panel Replay on Dell XPS 16 DA16260 as a quirk")
removed locally so the feature could be exercised.
The sink reports a persistently latched error:
Sink PANEL-REPLAY status: 0x2 [active, display from RFB]
Sink PANEL-REPLAY error status: 0x1:
PANEL-REPLAY Link CRC error
which survives across reads indefinitely, while dmesg stays silent and
Panel Replay Selective Update remains enabled.
Use the same conditional offset when clearing. psr->panel_replay_enabled
cannot be used at that point because intel_psr_disable_locked() clears it
earlier in the same function whenever an error was detected, which is
exactly the case that needs the Panel Replay offset, so save it beforehand.
v2: use a copy of panel_replay_enabled taken before
intel_psr_disable_locked() clears it. In v1 the condition was evaluated
after the disable, so it selected DP_PSR_ERROR_STATUS in the error path
and the patch was a no-op there. Caught by Sashiko AI review.
Signed-off-by: Jake Steinman <j@metarealtyinc.ca>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20260901205956.130779-1-j@metarealtyinc.ca
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
[Rodrigo: adjusted commit message based on checkpatch]
The legacy cursor path forced all joiner updates to the
slow path by checking joiner_pipes.
Drop the condition so that joiner cursor updates can use
the fast path.
v4: Trimmed to only the joiner_pipes gate drop. [Chaitanya]
Assisted-by: Claude:claude-sonnet-4.6
Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260901072813.2596383-6-nemesa.garg@intel.com
Iterate over all joined pipes when arming/disabling the cursor plane so
secondary pipes are updated together with the primary. The pin, check
and state duplication for secondary pipes was already prepared in the
previous commit; this converts the update_arm pass to a loop over the
joined_pipe_state[] array.
Because the whole loop runs inside a single primary vblank-evade,
sample intel_crtc_get_vblank_counter() per pipe around each arm and
emit a drm_err() if the counter ticks during that pipe's own
programming.
v2: Check primary and secondary pipe together. [Ville]
v3: Use struct intel_cursor_joiner_state. [Ville]
v4: Add per-pipe vblank straddle detection around the arm loop. [Chaitanya]
v5: Move straddle check outside the loop to cover all pipes together.
Sample vblank counter from primary pipe only.
Move drm_err() after local_irq_enable(). [Chaitanya]
Assisted-by: Claude:claude-sonnet-4.6
Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260901072813.2596383-5-nemesa.garg@intel.com
In joiner mode the fast path cursor update must handle
secondary pipes. Iterate over all joined pipes uniformly
to duplicate plane state, run check_plane(), pin the
framebuffer and on success swap in the new plane state
for each secondary cursor.
Track every successfully prepared pipe in a joined_pipe_state[] array
of struct intel_cursor_joiner_state so that later frontbuffer, unpin
and error-cleanup paths treat primary and secondaries uniformly,
and ensures the primary's pinned framebuffer is released if a
secondary fails partway through.
Convert the primary-only vblank unpin block into a loop over the
joined_pipe_state[] array so each pipe's old cursor framebuffer is
scheduled for unpin (or unpinned inline when unchanged) independently.
All unpin work is armed on the primary crtc's vblank (&crtc->base),
consistent with the single primary vblank evasion used above.
v2: Use intel_crtc_joined_pipe_mask(). [Ville]
Add locking mechanism. [Ville]
v3: Drop the per-pipe fastpath mutex array. [sashiko]
v4: Fold parallel arrays into struct intel_cursor_joiner_state
joined_pipe_state[]. Unify primary/secondary in a single loop.
Use bare check_plane(). [Chaitanya]
v5: Fix secondary uapi.crtc to each pipe's own crtc.
Rename intel_cursor_pipe to intel_cursor_joiner_state and
joined[] to joined_pipe_state[]. [Chaitanya]
v6: Mirror primary uapi into secondary hw state, don't set uapi.crtc.
[sashiko]
v7: Squash the per-pipe cursor unpin scheduling into this patch.[Chaitanya]
v8: Resolve checkpatch errors.
Assisted-by: Claude:claude-sonnet-4.6
Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260901072813.2596383-4-nemesa.garg@intel.com
Move cursor fast path plane state update into helper
function. The target hw.crtc is passed as a parameter
so a later patch can reuse the helper for joiner
secondary pipes, where hw.crtc points at the secondary
being programmed while uapi.crtc stays on the primary.
v4: Drop uapi.crtc assignment from the helper. [Chaitanya]
Assisted-by: Claude:claude-sonnet-4.6
Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260901072813.2596383-3-nemesa.garg@intel.com
In joiner mode, secondary cursor commits may still be running
even when the primary cursor commit is done. Walking the secondary
pipes also requires holding the secondary planes modeset locks.
Add intel_cursor_lock_joined_planes() to acquire modeset locks
for all secondary cursor planes. Check all joined cursor commit
status before taking the fast path. If any commit is still pending,
fallback to slow path.
v2: Use intel_crtc_joined_pipe_mask(). [Ville]
v3: Lock secondary cursor CRTCs and planes. [sashiko]
v4: Iterate the full joined mask uniformly in both helpers, no
primary special-case.
Move the parameter-change check above the lock acquisition so
we don't grab secondary locks just to fall to slow path. [Chaitanya]
v5: Remove extra header declaration. [Chaitanya]
Assisted-by: Claude:claude-sonnet-4.6
Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260901072813.2596383-2-nemesa.garg@intel.com
SDP splitting for 128b/132b (UHBR) SST audio must only be enabled when
the sink advertises support for it. Previously sdp_split_enable
was set for every UHBR SST stream carrying audio, regardless of sink
capability.
In MST mode SDP splitting is inherently supported, so the sink
capability check (DP_SST_SPLIT_SDP_CAP) is applied only to the SST path.
Fixes: 8853750dba ("drm/i915: Enable SDP split for DP2.0")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260825073204.872441-1-mitulkumar.ajitkumar.golani@intel.com
Variable naming of val and val1 should match register macro naming.
Historically, corresponding macros were named GEN6_PCODE_DATA and
GEN6_PCODE_DATA1.
Rename register macro GEN6_PCODE_DATA to GEN6_PCODE_DATA0 since spec
appended '0' to the register name. Rename val into val0 in functions
declaring val1 for both i915-specific and shared display code.
v4->v5
- clean changelog's versioning
v3->v4
- split i915 changes from xe (Jani)
- apply the rename to the read()'s signature as well (Sashiko)
v2->v3
- resolve conflict from rebase
v1->v2
- rebase onto drm-tip (Jani)
Bspec: 19978
Suggested-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/20260828190956.2622350-2-michal.grzelak@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We don't use any of the functions inclued in intel_clock_gating.h in
the intel_display.c code anymore. Remove the respective include.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260817092911.342072-4-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
The remaining platform-specific display clock gating functions are
still called directly by i915.
Extend intel_display_init_clock_gating() so that it calls the correct
functions for the remaining platforms.
This groups Broadwell's three display operations into a single
function. This changes the call order slighlty in relation to
non-display workarounds, but it shouldn't be a problem. For IVB, we
move the trickle-feed programming to the display helper and runs with
the other display register setup.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260817092911.342072-3-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Instead of exporting many of the display clock gating functions,
consolidate them into a single function that checks the platform and
calls the appropriate platform-specific function.
Start consolidating the Gen 9 functions first into a new
intel_display_init_clock_gating() function.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260817092911.342072-2-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Now that intel_cdclk_{pre,post}_notify() are implemented via vfuncs
there is no need to keep them inside the .set_cdclk() hooks. Move
the calls one level up to intel_cdclk_set_cdclk().
We do need to adjust {skl,bxt}_cdclk_(un)init_hw() to call the wrapper
rather than the low level implementation directly, or else they would
not do the pcode notification anymore.
The two slight functional changes here are:
- bdw_set_cdclk() might theoretically bail out after doing the
pre notification, but that codepath would only come into play
if the hardware is seriously misprogrammed, so should never happen
- cdclk hw readout is still done from .set_cdclk(), so that now
happens before the post notify vs. previously the readout happened
before it. This should not matter as the readout is not affected
by the post notify (since we can't actually read out anything from
pcode).
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260826134033.13976-15-ville.syrjala@linux.intel.com
Turn the cdclk pcode pre/post notify functions into vfuncs.
Mainly to get rid of the hideous if-ladders in bxt_set_cdclk().
DG2 is currently doing its own thing with its pcode notify funcs so
can't be converted yet. And MTL+ go via the pmdemand stuff so this
is all supposedly handled elsewhere.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260826134033.13976-14-ville.syrjala@linux.intel.com
Extract the BXT/GLK pcode notify stuff to a few small helpers.
The plan is to unify these between all the platforms and turn
them into vfuncs.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260826134033.13976-13-ville.syrjala@linux.intel.com
Extract the SKL/ICL+ pcode notify stuff to a few small helpers.
The plan is to unify these between all the platforms and turn
them into vfuncs.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260826134033.13976-12-ville.syrjala@linux.intel.com
Extract the BDW pcode notify stuff to a few small helpers. The
plan is to unify these between all the platforms and turn them
into vfuncs.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260826134033.13976-11-ville.syrjala@linux.intel.com
The debug spew for the cdclk pcode per/post notify is very
inconsistent between different platforms. Unify it all to
the same form.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260826134033.13976-10-ville.syrjala@linux.intel.com
The control flow between the pcode pre and post notifications in
bxt_set_cdclk() is written in two different ways, even though
they end up doing the same thing. Unify the code.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260826134033.13976-9-ville.syrjala@linux.intel.com
Overwrite cdclk.hw.voltage_level from intel_update_cdclk() at the
end on bxt_set_cdclk() also on bxt/glk. While this isn't actually
necessary due to bxt/glk not having any extra DDI based voltage
level requirements, it does avoid one less silly 'if' in the code.
On icl+ the value derived by bxt_get_cdclk() may not be correct
if the voltage level was bumped up due to DDI requirements, thus
overwriting the assumed value is crucial there.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260826134033.13976-7-ville.syrjala@linux.intel.com
SKL_CDCLK_PREPARE_FOR_CHANGE == DISPLAY_TO_PCODE_VOLTAGE(3) so
we are currently forcing the voltage level to 3 all the time on
DG2. Remove SKL_CDCLK_PREPARE_FOR_CHANGE from the mask to avoid
this.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260826134033.13976-6-ville.syrjala@linux.intel.com
We're currently skipping the pcode notifies on DG2 if the CDCLK isn't
changing while the power well counts would still need updating.
Do the pcode notifications also for pure pipe power well changes.
The lower level intel_set_cdclk() will skip doing any real work if the
actual CDCLK stuff doesn't need to change, so it's fine to call it even
if only the power wells need updating.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260826134033.13976-5-ville.syrjala@linux.intel.com
The pcode post notify needs to happen after the CDCLK has been
changed, not before. Also move the pre_notify call a bit for the
sake of symmetry.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260826134033.13976-4-ville.syrjala@linux.intel.com
We are currently trying to pass the CDCLK in kHz to the pcode
on DG2, while the pcode expects a value in MHz units. Adjust
the units appropriately.
v2: Call it 'cdclk_mhz' (Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260826134033.13976-3-ville.syrjala@linux.intel.com
We already changed the actual cdclk frequency by the time we do
the pcode post notify. So skipping the subsequent readout is plain
wrong.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260826134033.13976-2-ville.syrjala@linux.intel.com
dg2_power_well_count() is supposed to return an integer,
not a boolean. Make it so.
Fixes: 9112ce99c1 ("drm/i915/cdclk: Extract dg2_power_well_count()")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260826143100.19401-1-ville.syrjala@linux.intel.com
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
We have several open coded checks for the platform's
cd2x pipe select capability, each written slightly
differently. Move it all into a common
has_cd2x_pipe_select() helper.
No functional changes as the previous 'DISPLAY_VER < 30'
checks were in codepaths that already exclude pre-bxt
platforms, and intel_cdclk_can_cd2x_update() already
rejects PTL+ via the later HAS_CDCLK_SQUASH() check.
Also update the docs for the register bitfield while at it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260717155107.17801-2-ville.syrjala@linux.intel.com
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
icl_plane_disable_sel_fetch_arm() wrote SEL_FETCH_PLANE_CTL = 0 only when
crtc_state->enable_psr2_sel_fetch was set. If a plane was disabled after
selective fetch had been turned off, the guard fired early and left the
register's enable bit set in hardware.
The bit is harmless until selective fetch is re-enabled. When it is, the
hardware resumes fetching for the now-disabled plane and keeps its old DDB
range reserved.
i9xx_cursor_disable_sel_fetch_arm() has the same guard on SEL_FETCH_CUR_CTL
and is fixed the same way.
v2: Add same check for cursor also. [sashiko]
Cc: stable@vger.kernel.org
Fixes: b1f5279b59 ("drm/i915/psr: Move plane sel fetch configuration into plane source files")
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8739
Assisted-by: GitHub-Copilot:claude-opus-4.6
Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260818095149.2172935-1-nemesa.garg@intel.com
PHY_NONE is not really used, but we define it and, thus, need to check
for it in a few places we use phy. The only potential places where
phy may become PHY_NONE, is in intel_port_to_phy(), where it derives
from port, which can be PORT_NONE. Many of its callers don't check
for PHY_NONE, which can cause unknown behavior. Additionally, this
can only happen if the encoder used has PORT_NONE, which should not be
the case either, without unexpected consequences.
Remove the PHY_NONE definition entirely and add a couple of WARNs at
the relevant places, just to be sure.
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/20260609095525.570614-5-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
BIT() takes a non-negative shift amount, but cpu_transcoder is of type
enum transcoder, which can in theory be INVALID_TRANSCODER (-1).
This is not a problem with the current implementation, because
cpu_transcoder is always valid when this code is reached, but it's
more robust to cast to unsigned so the shift is always well-defined.
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/20260609095525.570614-4-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
ICL_DPCLKA_CFGCR0 has a 2-bit DDI_CLK_SEL field per combo PHY, for
PHY_A..PHY_D only. Any other phy value (PHY_NONE, TypeC/SNPS PHYs) is
not valid here.
This is not a problem with the current implementation, because phy is
always valid when these macros are called, but it's more robust to
cast to unsigned so the shift is always well-defined.
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/20260609095525.570614-3-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
HSW_AUD_PIN_ELD_CP_VLD has a 4-bit field per transcoder for
TRANSCODER_A..TRANSCODER_D only (bits 0..15). Any other transcoder
value (TRANSCODER_EDP, TRANSCODER_DSI_*, INVALID_TRANSCODER) is not
valid here.
This is not a problem with the current implementation, because trans
is always valid when these macros are called, but it's more robust to
mask the index to the low 2 bits so the shift is always well-defined.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/20260609095525.570614-2-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
DDI_CLK_VALFREQ is programmed with the port clock, which for DP is the
symbol clock computed assuming 8b/10b encoding (link_rate / 10). For
DP 128b/132b (UHBR) rates and for HDMI FRL the port clock needs to
be modified.
DDI_CLK_VALFREQ does not have any functional impact on H/w, it
only records the frequency S/w intends to set.
Use intel_ddi_link_symbol_clock() to write the correct DDI clock in
kHz
Fixes: 5ec58d7149 ("drm/i915/lt_phy: Add .enable_clock hook on DDI")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260811175844.2613721-4-suraj.kandpal@intel.com
DDI_CLK_VALFREQ is programmed with the port clock, which for DP is the
symbol clock computed assuming 8b/10b encoding (link_rate / 10). For
DP 128b/132b (UHBR) rates and for HDMI FRL the port clock needs to
be modfied.
DDI_CLK_VALFREQ does not have any functional impact on H/w, it
only records the frequency S/w intends to set.
Use intel_ddi_link_symbol_clock() to write the correct DDI clock in
kHz.
Fixes: 51390cc0e0 ("drm/i915/mtl: Add Support for C10 PHY message bus and pll programming")
Fixes: 73fc3abcb7 ("drm/i915/mtl: Enabling/disabling sequence Thunderbolt pll")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260811175844.2613721-3-suraj.kandpal@intel.com
Add intel_ddi_link_symbol_clock() to return the DDI clock frequency for
a given port clock:
DP 8b/10b : rate
DP 128b/132b (UHBR) : (10 / 32) * rate
HDMI FRL : (10 / 18) * rate
HDMI TMDS : rate
The DP case reuses intel_dp_link_symbol_clock().
This will help in upcoming commits to decide value to be written
in DDI_CLK_VALFREQ.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260811175844.2613721-2-suraj.kandpal@intel.com
Reject invalid joiner forcing more thoroughly, taking into account
whether bigjoiner or uncompressed joiner is available, and whether the
requested number of pipes can actually be joined.
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/df39b8f30d27a441465b4d9bd42d4db982e5db2b.1786105831.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Skip joining for pipes that can't work as joiner primary pipe for the
number of pipes being joined. This limits the invalid combos early,
instead of ending up with crtc_state->joiner_pipes that would fail
during modeset. Before, crtc_state->joiner pipes could have ended up
including pipes that do not exist on the platform.
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/dc1c7fc45d4da7d3fd1bd8b94c30c78d69aa0742.1786105831.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Make intel_dp_can_join(), and subsequently
intel_dp_joiner_candidate_valid() and for_each_joiner_candidate() more
strict about pipes actually available for joining by using
intel_joiner_valid_primary_pipe_mask().
This rejects some invalid combos early for both mode enumeration and
compute config.
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/efc330687f8299e5725564c3ed90d5d8e6aa0eb2.1786105831.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Multiplying the max dotclock based on joiner availability on the
platform alone does not take into account the actual pipes (possibly
with some fused) available for joining.
Limit the max joined dotclock based on the actual pipes available for
joining. Add helpers for figuring out the valid primary pipes, based on
having the required joiners and amount of consecutive pipes available.
v2: Check for consecutive pipes available (Ankit)
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/3c615440f018af779a3a522f14637d2993f7af03.1786105831.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
mst_stream_compute_config() called intel_pfit_compute_config() twice
in a row.
commit 5ce9ac1531 ("drm/i915/mst: Call intel_pfit_compute_config()
for sharpness filter")
was erroneously cherry-picked to the fixes tree while
commit ca97f5546f ("drm/i915/mst: Call intel_pfit_compute_config()
for sharpness filter")
was already in there.
Drop the redundant duplicate call.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Nemesa Garg <nemesa.garg@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Fixes: 5ce9ac1531 ("drm/i915/mst: Call intel_pfit_compute_config() for sharpness filter")
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patch.msgid.link/20260806074819.2631970-1-chaitanya.kumar.borah@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
[Rodrigo: adjusted commit message]
Refactor intel_hdmi_dsc_get_num_slices to remove dependency on
intel_crtc_state structure by accepting display mode and output format
as parameters instead.
This makes the function reusable for mode_valid cases where
crtc_state is not present.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260805035027.3473398-3-ankit.k.nautiyal@intel.com
There are workarounds display needs to apply depending on information
only available to the core driver. Add a display parent interface for
the query. For starters, there's only one workaround like this, so keep
it simple instead of over-engineering.
This lets us drop an #ifdef I915 as well as xe dependency on some
display headers.
v2: git add xe_display_wa.h
v3: Add a comments about usage (Suraj)
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260803115417.1760484-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
