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>
Move the core driver TDF call to display parent interface to avoid
direct calls from display to xe driver.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260728170029.608289-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Now that DG2 has a DPLL manager and its users are prepared to obtain
clock state through the framework, switch the platform over to use the
shared DPLL manager.
Remove specific MPLLB state verification and use .compare_hw function
hook to compare HW and SW PLL states.
Assisted-by: Copilot:claude-sonnet-4-6
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/20260630115336.1059976-5-mika.kahola@intel.com
Prepare DG2 users to obtain clock state and reserve PLLs through the
shared DPLL framework.
Replace the DG2-specific compute hook with the generic framework-backed
helpers.
Assisted-by: Copilot:claude-sonnet-4-6
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/20260630115336.1059976-4-mika.kahola@intel.com
