Add accessor functions for Snps to read requested table from VBT #57.
Parse the requested table and transform data into port's buffer.
Actual data is fully stored in the lowest byte although each entry is 4
bytes wide. Thus convert u32 into u8 and store the data.
For C20, use 6th table if encoder supports DP 2.0 or higher. Otherwise
use 5th table for DP.
For C20, tables 1-4 are not used at all and are most likely to be
zeroed. 5th table is used for any mode below DP 2.0 (exclusive). 6th
table is used for any mode above DP 2.0 (inclusive).
For C10, use 2nd table for external DP if encoder supports any mode
beyond or including HBR2. Use 1st table if external DP encoder supports
anything lower than HBR2. For eDP, use 4th table if encoder supports
HBR3. Otherwise use 3rd table for eDP.
For C10, 1st table is used for external DP with modes below HBR2
(exclusive). 2nd table is used for external DP with modes higher than
HBR2 (inclusive). 3rd table is used for eDP with modes lower than HBR3
(exclusive). 4th table is used for eDP with modes higher than HBR3
(inclusive).
Indices for other tables have not yet been observed to be used as of
now.
There are no changes to intel_ddi_dp_level() since selection of correct
row of intel_ddi_buf_trans_entry is same as when no override request has
been done.
v11->v12
- don't set vspeo->num_entries per PHY
- don't refer to 1st table as fallback for non-DP for C10 (Sashiko)
v10->v11
- remove no-longer-relevant check for NULL devdata (Jani)
- initialize local variables at declaration block (Jani)
- branch with 'else` instead of initializing twice (Jani)
- use blank line before 'return` (Jani)
v9->v10
- call dedicated VS/PE-O vfunc
- drop deconstifying default tables (Suraj, Jani)
- cache `entries` into const field after data is overwritten (Jani)
v8->v9
- init vspeo before using it
- deconstify intel_ddi_buf_trans_entry
v7->v8
- remove comments (Suraj)
- add check for LT (Suraj)
v6->v7
- handle VS/PE-O's VBT details in intel_bios_* functions (Jani)
- remove vspeo's cast to (void *) (Jani)
- check devdata->vspeo if VS/PE-O was requested
- call encoder->get_buf_trans() once (Jani)
- return NULL from intel_bios_get_* when using default (Jani)
- validate VS/PE-O in intel_bios.c (Jani)
- inline mtl_{c10,c20}_get_vspeo_buf_trans()
- remove temporarily LT
v4->v5
- blend index computation with table parsing
- remove enums entirely
- change funcs prefix from snps_ to mtl_ (Suraj)
- add spaces around operators (Suraj)
- remove spaces after type casting (Suraj)
- remove INTEL_DISPLAY_STATE_WARN (Suraj)
v3->v4
- stick to solely changing VBT data into current structures (Jani)
- move iterator declaration to declaration block (Suraj)
v2->v3
- remove unnecessary braces from if block (Suraj)
- return -EINVAL instead of -1 (Suraj)
Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260904123148.2165596-7-michal.grzelak@intel.com
Choosing correct table for Vswing / Pre-emphasis Override is platform
specific. It also requires different checks that are already used for
choosing predefined tables.
Add new get_buf_trans_override() vfunc into intel_encoder returning
deparsed table from VBT#57. In next patches, set it inside already
present if-ladder from intel_ddi_buf_trans_init() instead of duplicating
it.
Note that get_buf_trans() cannot be overwritten since there are cases
when we need to rollback although VS/PE-O was requested, eg. DP is not
connected or feature is not yet implemented for the platform. Assume
that vfunc returns NULL on rollback and return predefined tables.
Suggested-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260904123148.2165596-6-michal.grzelak@intel.com
Every devdata needs VS/PE-O dedicated buffers since each port can
request an override. Add intel_ddi_buf_trans{,_entry} pointers into
intel_bios_encoder_data.
Allocate struct intel_ddi_buf_trans{,_entry} for the port if VS/PE-O was
requested and is supported. Keep NULL in vspeo if any allocation failed
or VS/PE-O was not requested. It will be used later for checking if
override should actually take place.
Note that we theoretically could store intel_ddi_buf_trans_entry inside
`entries` field of newly allocated intel_ddi_buf_trans. However it will
be impossible to overwrite the buffer during intel_ddi_get_buf_trans()
without discarding const qualifier of `entries` field. This would
involve either void casting or deconstifying entries field and in turn
all predefined tables as well. Thus add a separate non-const qualified
field into intel_bios_encoder_data for the buffer, which after
overwriting will be promoted to be const qualified.
Deallocate the buffer as well as entries if requested.
v11->v12
- set vspeo->num_entries once (Sashiko)
- free allocated vspeo->entries (Sashiko)
v9->v10
- add separate non-const field for `entries` caching
- cache `entries` into const field after data is overwritten (Jani)
v4->v5
- set devdata->vspeo->num_entries in intel_bios.c
Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260904123148.2165596-5-michal.grzelak@intel.com
Store tables, number of tables, number of rows and number of columns in
intel_vbt_data when search for the VBT #57 has succeeded. Structurize
all VS/PE-O relevant metadata inside anonymous struct named as vspeo.
Presence of C20 or newer PHY causes each table to contain 16 rows. Each
table contains 10 rows in case C20 PHY is absent. Use display version to
determine number of rows since there is no helper in intel_bios.c to
check presence of any C20+ PHY. pre-MTL platforms should have 10 rows
while MTL+ should have 16 rows.
v5->v6
- add Bspec (Suraj)
v3->v4
- remove unnecessary init of VS/PE-O metadata (Suraj)
- add helper for computing number of rows (Suraj)
- fix num_rows's type (Jani, Suraj)
- declare num_rows (Suraj)
Bspec: 68963
Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260904123148.2165596-3-michal.grzelak@intel.com
Start searching for Vswing / Preemphasis Override Block during VBT
parsing at init_bdb_blocks().
Check for failure since pre-ICL GOPs do not contain the block. Check
also if VBT version is appropriately up-to-date.
v6->v7
- parse VBT#57 before blocks dependent on child device list (Jani)
- remove debug message (Suraj)
v3->v4
- add Bspec (Suraj)
Bspec: 32063
Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260904123148.2165596-2-michal.grzelak@intel.com
intel_crtc_duplicate_state() resets use_dsb to false but not
use_flipq, letting a stale true value survive into the new state.
Reset use_flipq alongside use_dsb.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patch.msgid.link/20260902140848.915941-1-mika.kahola@intel.com
Add bandwidth check to determine whether a given audio sample rate and
channel count can be carried within the hblank period for HDMI TMDS mode.
Use this check to prune unsupported sample rates from each SAD in the
ELD during intel_audio_compute_config(). SADs with no remaining
supported rates are removed entirely.
Sample rates are pruned rather than channel counts, since compressed
formats (e.g. AC-3) are associated with specific channel counts.
v2:
- Use DIV64_U64_ROUND_UP() instead of DIV_ROUND_UP_ULL() to avoid
do_div() truncating the 64-bit divisor to 32-bit, which caused
audio_packets_line to be wildly inflated and all SADs to be pruned.
- Guard intel_audio_hdmi_eld_compute_config() against HDMI FRL modes.
(Remove it when BW calculations for FRL are added.)
v3:
- Rebase
v4:
- Rework SAD removal into a single-pass, two-pointer compaction
instead of memmove-ing the tail on every removal. (Jani)
v5:
- Drop the FRL guard, i915 doesn't support FRL yet. (Ankit)
- s/required_tmds/hblank_audio_min (Ankit)
- Add HDMI_TMDS_AUDIO_PACKETS_LINE_MAX macro
instead of a magic number 18. (Ankit)
- Use drm_eld_sad_get()/drm_eld_sad_set() instead of
raw ELD byte access. (Ankit)
- Drop extra blank line. (Ankit)
BSpec: 68944
Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Vinod Govindapillai <vinod.govindapillai@intel.com>
Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Assisted-by: GitHub-Copilot:claude-opus-4.6
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-3-chaitanya.kumar.borah@intel.com
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>
