Imre Deak [Mon, 22 Dec 2025 15:35:47 +0000 (17:35 +0200)]
drm/i915/dp: Simplify computing the DSC compressed BPP for DP-MST
The minimum/maximum DSC input (i.e. pipe) and compressed (i.e. link) BPP
limits are computed already in intel_dp_compute_config_limits(), so
there is no need to do this again in
mst_stream_dsc_compute_link_config() called later. Remove the
corresponding alignments from the latter function and use the
precomputed (aligned and within bounds) maximum pipe BPP and the min/max
compressed BPP values instead as-is.
Imre Deak [Mon, 22 Dec 2025 15:35:44 +0000 (17:35 +0200)]
drm/i915/dp: Simplify computing forced DSC BPP for DP-SST
If dsc_compute_compressed_bpp() failed with a forced pipe BPP value
(where the forced pipe BPP value itself is valid within the min/max pipe
BPP limits), the function will also fail when called with the maximum
pipe BPP value: dsc_compute_compressed_bpp() will try all compressed
BPPs below the passed in pipe BPP value and if the function failed with
a given (low) compressed BPP value it will also fail with a compressed
BPP value higher than the one which failed already.
Based on the above remove the logic to retry computing a compressed BPP
value with the maximum pipe BPP value if computing the compressed BPP
failed already with the (lower) forced pipe BPP value.
Imre Deak [Mon, 22 Dec 2025 15:35:43 +0000 (17:35 +0200)]
drm/i915/dp: Simplify computing DSC BPPs for DP-SST
The maximum pipe BPP value (used as the DSC input BPP) has been aligned
already to the corresponding source/sink input BPP capabilities in
intel_dp_compute_config_limits(). So it isn't needed to perform the same
alignment again in intel_dp_dsc_compute_pipe_bpp() called later, this
function can simply use the already aligned maximum pipe BPP value, do
that.
Also, there is no point in trying pipe BPP values lower than the
maximum: this would only make dsc_compute_compressed_bpp() start with a
lower _compressed_ BPP value, but this lower compressed BPP value has
been tried already when dsc_compute_compressed_bpp() was called with the
higher pipe BPP value (i.e. the first dsc_compute_compressed_bpp() call
tries already all the possible compressed BPP values which are all below
the pipe BPP value passed to it). Simplify the function accordingly
trying only the maximum pipe BPP value.
Imre Deak [Mon, 22 Dec 2025 15:35:42 +0000 (17:35 +0200)]
drm/i915/dp: Simplify computing DSC BPPs for eDP
The maximum pipe BPP value (used as the DSC input BPP) has been aligned
already to the corresponding source/sink input BPP capabilities in
intel_dp_compute_config_limits(). So it isn't needed to perform the same
alignment again in intel_edp_dsc_compute_pipe_bpp() called later, this
function can simply use the already aligned maximum pipe BPP value, do
that.
Imre Deak [Mon, 22 Dec 2025 15:35:41 +0000 (17:35 +0200)]
drm/i915/dp: Use helpers to align min/max compressed BPPs
The minimum/maximum compressed BPP values are aligned/bounded in
intel_dp_compute_link_bpp_limits() to the corresponding source limits.
The minimum compressed BPP value doesn't change afterwards, so no need
to align it again, remove that.
The maximum compressed BPP, which depends on the pipe BPP value still
needs to be aligned, since the pipe BPP value could change after the
above limits were computed, via intel_dp_force_dsc_pipe_bpp(). Use the
corresponding helper for this alignment instead of open-coding the same.
Imre Deak [Mon, 22 Dec 2025 15:35:40 +0000 (17:35 +0200)]
drm/i915/dp: Unify detect and compute time DSC mode BW validation
Atm, a DP DSC video mode's required BW vs. the available BW is
determined by calculating the maximum compressed BPP value allowed by
the available BW. Doing that using a closed-form formula as it's done
atm (vs. an iterative way) is problematic, since the overhead of the
required BW itself depends on the BPP value being calculated. Instead of
that calculate the required BW for the minimum compressed BPP value
supported both by the source and the sink and check this BW against the
available BW. This change also aligns the BW calculation during mode
validation with how this is done during state computation, calculating
the required effective data rate with the corresponding BW overhead.
Imre Deak [Mon, 22 Dec 2025 15:35:39 +0000 (17:35 +0200)]
drm/i915/dp: Add intel_dp_mode_valid_with_dsc()
Add intel_dp_mode_valid_with_dsc() and call this for an SST/MST mode
validation to prepare for a follow-up change using a way to verify the
mode's required BW the same way this is done elsewhere during state
computation (which in turn depends on the mode's effective data rate
with the corresponding BW overhead).
Imre Deak [Mon, 22 Dec 2025 15:35:35 +0000 (17:35 +0200)]
drm/i915/dp: Pass intel_output_format to intel_dp_dsc_sink_{min_max}_compressed_bpp()
Prepare for follow-up changes also calling
intel_dp_dsc_min_sink_compressed_bpp() /
intel_dp_dsc_max_sink_compressed_bpp_x16()
without an intel_crtc_state.
While at it remove the stale function declarations from the header file.
Imre Deak [Mon, 22 Dec 2025 15:35:34 +0000 (17:35 +0200)]
drm/i915/dp: Drop intel_dp parameter from intel_dp_compute_config_link_bpp_limits()
The intel_dp pointer can be deducted from the connector pointer, so it's
enough to pass only connector to
intel_dp_compute_config_link_bpp_limits(), do so.
Imre Deak [Mon, 22 Dec 2025 15:35:33 +0000 (17:35 +0200)]
drm/i915/dp: Align min/max compressed BPPs when calculating BPP limits
Align the minimum/maximum DSC compressed BPPs to the corresponding
source compressed BPP limits already when computing the BPP limits. This
alignment is also performed later during state computation, however
there is no reason to initialize the limits to an unaligned/incorrect
value.
Imre Deak [Mon, 22 Dec 2025 15:35:32 +0000 (17:35 +0200)]
drm/i915/dp: Align min/max DSC input BPPs to sink caps
Align the minimum/maximum DSC input BPPs to the corresponding sink DSC
input BPP capability limits already when computing the BPP limits. This
alignment is also performed later during state computation, however
there is no reason to initialize the limits to an unaligned/incorrect
value.
Ben Dooks [Thu, 8 Jan 2026 20:12:03 +0000 (15:12 -0500)]
drm/i915/guc: make 'guc_hw_reg_state' static as it isn't exported
The guc_hw_reg_state array is not exported, so make it static.
Fixes the following sparse warning:
drivers/gpu/drm/i915/i915_gpu_error.c:692:3: warning: symbol 'guc_hw_reg_state' was not declared. Should it be static?
Fixes: ba391a102ec11 ("drm/i915/guc: Include the GuC registers in the error state") Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260108201202.59250-2-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Gustavo Sousa [Tue, 6 Jan 2026 21:40:21 +0000 (18:40 -0300)]
drm/i915/cdclk: Incorporate Xe3_LPD changes for CD2X divider
On Xe3_LPD, there is no instruction to program the CD2X divider anymore
and the hardware is expected to always use the default value of 0b00,
meaning "divide by 1".
With that, the CDCLK_CTL register was changed so that:
(1) The field "CD2X Divider Select" became a debug-only field.
Because we are programming CDCLK_CTL with a direct write instead
of read-modify-write operation, we still need to program "CD2X
Divider Select" in order to keep the field from deviating from its
default value. Let's, however, throw a warning if we encounter a
CDCLK value that would result in an unexpected value for that
field.
(2) The field "CD2X Pipe Select" has been removed. In fact, some
debugging in a PTL machine showed that such field comes back as
zero after writing a non-zero value to it. As such, do not
program it starting with Xe3_LPD.
Fix kernel-doc warnings on struct intel_lb_component_ops:
Warning: include/drm/intel/intel_lb_mei_interface.h:55 Incorrect use of
kernel-doc format: * push_payload - Sends a payload to the
authentication firmware
And a bunch more. There isn't really support for documenting function
pointer struct members in kernel-doc, but at least reference the member
properly.
Fixes: 741eeabb7c78 ("mei: late_bind: add late binding component driver") Cc: Alexander Usyskin <alexander.usyskin@intel.com> Reviewed-by: Nitin Gote <nitin.r.gote@intel.com> Link: https://patch.msgid.link/20260107160226.2381388-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Suraj Kandpal [Mon, 5 Jan 2026 05:59:37 +0000 (11:29 +0530)]
drm/i915/ltphy: Provide protection against unsupported modes
We need to make sure we return some port clock in case we have
unsupported LT PHY modes or if we were not able to read the LT PHY state
for whatever reason and the mode ends up being 0.
Suraj Kandpal [Mon, 5 Jan 2026 05:59:36 +0000 (11:29 +0530)]
drm/i915/ltphy: Compare only certain fields in state verify function
Verify only the config[0,2] fields in the LT PHY state since these
are the only reliable values we can get back when we read the VDR
registers. The reason being that the state does not persist for other
VDR registers when power gating comes into picture.
Though not ideal this change does not hit us badly in perspective of how
we use the compare function to decide if fastset is required or if we
wrote the state correctly. VDR0_CONFIG and VDR1_CONFIG hold the values
that indicate the PLL operating mode and link rate which is usually
what we need to check if something has changed or not.
Suraj Kandpal [Mon, 5 Jan 2026 05:59:35 +0000 (11:29 +0530)]
drm/i915/ltphy: Remove state verification for LT PHY fields
Currently we do state verification for all VDR Registers.
Remove LT PHY State verification for all VDR register fields other
than VDR0_CONFIG and VDR2_CONFIG. The reason being that VDR0_CONFIG
and VDR2_CONFIG are the only reliable shadow register which hold onto
their values over the course of power gatings which happen internally
due to features like PSR/PR.
Jani Nikula [Wed, 31 Dec 2025 11:26:11 +0000 (13:26 +0200)]
drm/i915/gvt: include intel_display_limits.h where needed
In this case, it's actually gvt.h that needs I915_MAX_PORTS etc. from
intel_display_limits.h. Make this more evident by moving the include
there, instead of getting it via fb_decoder.h.
intel_display_limits.c was never supposed to be added. Remove it.
Fixes: f3255cf4490e ("drm/i915/display: Add APIs to be used by gvt to get the register offsets") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20251231103232.627666-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Jani Nikula [Mon, 29 Dec 2025 11:54:45 +0000 (13:54 +0200)]
drm/i915/utils: drop unnecessary ifdefs
The i915_utils.h and intel_display_utils.h were in some cases included
from the same files, the former via i915_drv.h and the latter
directly. This lead to a clash between MISSING_CASE() and
fetch_and_zero() defined in both, requiring ifdefs.
With the display dependency on i915_drv.h removed, we can also remove
the now unnecessary ifdefs.
Jani Nikula [Mon, 29 Dec 2025 11:54:43 +0000 (13:54 +0200)]
drm/i915: drop i915 param from i915_fence{, _context}_timeout()
The i915_fence_context_timeout() and i915_fence_timeout() functions both
have the struct drm_i915_private parameter, which is unused. It's likely
in preparation for something that just didn't end up happening.
Remove them, dropping the last struct drm_i915_private usage for xe
display build.
Mitul Golani [Tue, 23 Dec 2025 10:45:40 +0000 (16:15 +0530)]
drm/i915/vrr: Enable DC Balance
Enable DC Balance from vrr compute config and related hw flag.
Also to add pipe restrictions along with this.
--v2:
- Use dc balance check instead of source restriction.
--v3:
- Club pipe restriction check with dc balance enablement. (Ankit)
--v4:
- Separate out Pipe restrictions to patch#7
Mitul Golani [Tue, 23 Dec 2025 10:45:32 +0000 (16:15 +0530)]
drm/i915/display: Add DC Balance flip count operations
Track dc balance flip count with params per crtc. Increment
DC Balance Flip count before every flip to indicate DMC
firmware about new flip occurrence which needs to be adjusted
for dc balancing. This is tracked separately from legacy
FLIP_COUNT register also Reset DC balance flip count value
while disabling VRR adaptive mode, this is to start with
fresh counts when VRR adaptive refresh mode is triggered again.
Mitul Golani [Tue, 23 Dec 2025 10:45:31 +0000 (16:15 +0530)]
drm/i915/vrr: Add function to reset DC balance accumulated params
Add function which resets all accumulated DC Balance parameters
whenever adaptive mode of VRR goes off. This helps to give a
fresh start when VRR is re-enabled.
--v2:
- Typo, change crtc_state to old_crtc_state. (Ankit)
Mitul Golani [Tue, 23 Dec 2025 10:45:30 +0000 (16:15 +0530)]
drm/i915/vrr: Add function to check if DC Balance Possible
Add a function that checks if DC Balance enabling is possible on the
requested PIPE. Apart from the DISPLAY_VER check, account for current
firmware limitations, which only allow DC Balance on PIPE A and PIPE B.
Mitul Golani [Tue, 23 Dec 2025 10:45:29 +0000 (16:15 +0530)]
drm/i915/vrr: Add compute config for DC Balance params
Compute DC Balance parameters and tunable params based on
experiments.
--v2:
- Document tunable params. (Ankit)
--v3:
- Add line spaces to compute config. (Ankit)
- Remove redundancy checks.
--v4:
- Separate out conpute config to separate function.
- As all the valuse are being computed in scanlines, and slope
is still in usec, convert and store it to scanlines.
--v5:
- Update and add comments for slope calculation. (Ankit)
- Update early return conditions for dc balance compute. (Ankit)
--v6:
- Early return condition simplified for dc balance compute config. (Ankit)
- Make use of pipe restrictions to this patch. (Ankit)
--v7:
- Separate out PIPE_A and PIPE_B restrictions to other patch.(Ankit)
Ville Syrjälä [Tue, 23 Dec 2025 10:45:26 +0000 (16:15 +0530)]
drm/i915/vrr: Add functions to read out vmin/vmax stuff
Calculate delayed vblank start position with the help of added
vmin/vmax stuff for next frame and final computation.
--v2:
- Correct Author details.
--v3:
- Separate register details from this patch.
--v4:
- Add mask macros.
--v5:
- As live prefix params indicate timings for current frame,
read just _live prefix values instead of next frame timings as
done previously.
- Squash Refactor vrr params patch.
--v6:
- Use error code while returning invalid values. (Jani, Nikula)
Mitul Golani [Tue, 23 Dec 2025 10:45:25 +0000 (16:15 +0530)]
drm/i915/vrr: Add VRR DC balance registers
Add VRR register offsets and bits to access DC Balance configuration.
--v2:
- Separate register definitions. (Ankit)
- Remove usage of dev_priv. (Jani, Nikula)
--v3:
- Convert register address offset, from capital to small. (Ankit)
- Move mask bits near to register offsets. (Ankit)
--v4:
- Use _MMIO_TRANS wherever possible. (Jani)
--v5:
- Added LIVE Value registers for VMAX and FLIPLINE as provided by DMC fw
- For pipe B it is temporary and expected to change later once finalised.
--v6:
- Add live value registers for DCB VMAX/FLIPLINE.
--v7:
- Correct commit message file. (Jani Nikula)
- Add bits in highest to lowest order. (Jani Nikula)
--v8:
- Register/bitfields indentation changes as per i915_reg.h
mentioned format (Jani, Ankit)
Ville Syrjälä [Tue, 23 Dec 2025 10:45:24 +0000 (16:15 +0530)]
drm/i915/dmc: Add pipe dmc registers and bits for DC Balance
Add pipe dmc registers and access bits for DC Balance params
configuration and enablement.
--v2:
- Separate register definitions for transcoder and
pipe dmc. (Ankit)
- Use MMIO pipe macros instead of transcoder ones. (Ankit)
- Remove dev_priv use. (Jani, Nikula)
--v3:
- Add all register address, from capital alphabet to small. (Ankit)
- Add EVT CTL registers.
- Add co-author tag.
- Add event flag for Triggering DC Balance.
--v4:
- Add DCB Flip count and balance reset registers.
--v5:
- Correct macro usage for flip count. (Ankit)
- Use register offset in lower case.
Ankit Nautiyal [Fri, 19 Dec 2025 06:02:59 +0000 (11:32 +0530)]
drm/i915/gvt/display_helper: Get rid of #ifdef/#undefs
Now that i915/display macros have been substituted with wrappers that call
the new display-device helpers, we can drop the conflicting includes from
GVT and remove the temporary #ifdef/#undef macro overrides.
Ankit Nautiyal [Fri, 19 Dec 2025 06:02:58 +0000 (11:32 +0530)]
drm/i915/gvt: Use the appropriate header for the DPLL macro
The macro `DPLL_ID_SKL_DPLL0` is defined in
display/intel_dpll_mgr.h. Previously, GVT included the header
display/intel_display_core.h` because other macros also depended on it.
After porting those macros to use the new APIs, the only remaining
dependency was for the DPLL macro.
Replace the indirect include with the correct header and drop
intel_display_core.h to reduce unnecessary dependencies.
Ankit Nautiyal [Fri, 19 Dec 2025 06:02:57 +0000 (11:32 +0530)]
drm/i915/gvt: Change for_each_pipe to use pipe_valid API
Add a new API to check if a given pipe is valid using
DISPLAY_RUNTIME_INFO() for GVT.
Update GVT to use this API instead of accessing
`DISPLAY_RUNTIME_INFO->pipe_mask` directly in the `for_each_pipe` macro.
Since `for_each_pipe` is defined in i915/display/intel_display.h, which
also contains other macros used by gvt/display.c, we cannot drop the
intel_display.h header yet. This causes a build error because
`for_each_pipe` is included from both i915/display/intel_display.h and
gvt/display_helpers.h.
To resolve this, rename the GVT macro to `gvt_for_each_pipe` and make it
call the new API. This avoids exposing display internals and prepares for
display modularization.
v2:
- Expose API to check if pipe is valid rather than the runtime info
pipe mask. (Jani)
- Rename the macro to `gvt_for_each_pipe` to resolve build error.
v3:
- Use EXPORT_SYMBOL_NS_GPL(..., "I915_GVT"); (Jani)
- Use enum pipe at call sites instead of casting in the macro. (Jani)
Ankit Nautiyal [Fri, 19 Dec 2025 06:02:56 +0000 (11:32 +0530)]
drm/i915/gvt: Add header to use display offset functions in macros
Introduce gvt/display_helpers.h to make DISPLAY_MMIO_BASE and
INTEL_DISPLAY_DEVICE_*_OFFSET macros call exported display functions.
This lets GVT keep using existing register macros (e.g.,
TRANSCONF(display, pipe)) while ensuring offset calculations happen
through functions instead of accessing display internals.
Ideally, we would remove the display headers that define these macros,
but some macros in GVT still depend on them and have not yet been
ported. Keeping those headers leads to build conflicts, so as a
stopgap, we use temporary ifdef/undef blocks to override the macros
with API-backed versions. These will be removed once all dependent
macros are ported and the conflicting headers can be safely dropped.
Note:
TRANSCONF() expects a pipe index but some GVT callers pass a transcoder,
causing -Werror=enum-conversion.
Fix: cast to enum pipe in the GVT-side macro override.
This works for all cases as TRANSCODER_{A,B,C,D} all have 1:1 mapping to
PIPE_{A,B,C,D} except for TRANSCODER_EDP which is used in one place.
In any case, the cast preserves the previous behaviour.
v2:
- Remove prefix `gvt/` while including the header file. (Jani)
- Explain the rationale behind temporary ifdef/undefs and plan to drop
them. (Jani).
v3:
- Meld the patch to cast argument to enum pipe for the pipe-offset
macro. (Jani)
- Add a FIXME to highlight the cast. (Jani)
Ankit Nautiyal [Fri, 19 Dec 2025 06:02:55 +0000 (11:32 +0530)]
drm/i915/display: Add APIs to be used by gvt to get the register offsets
GVT code uses macros for register offsets that require display internal
structures. This makes clean separation of display code and
modularization difficult.
These APIs return absolute base offsets for the respective register
groups, allowing GVT to compute MMIO addresses without using internal
macros or struct fields. This prepares the path to separate
display-dependent code from i915/gvt/*.
v2:
- Build GVT APIs only when GVT is actually enabled. (Jani)
Introduce INTEL_DISPLAY_DEVICE_*_OFFSET() macros to compute absolute
MMIO offsets for pipe, transcoder, and cursor registers.
Update _MMIO_PIPE2/_MMIO_TRANS2/_MMIO_CURSOR2 to use these macros
for cleaner abstraction and to prepare for external API usage (e.g. GVT).
Also move DISPLAY_MMIO_BASE() to intel_display_device.h so it can be
abstracted in GVT, allowing register macros to resolve via
exported helpers rather than peeking into struct intel_display.
v2: Wrap the macro argument usages in parenthesis. (Jani)
Jani Nikula [Mon, 22 Dec 2025 12:34:03 +0000 (14:34 +0200)]
drm/i915/display: use to_intel_uncore() to avoid i915_drv.h
A number of places that include i915_drv.h only need it to get from
display to i915 to uncore. We have to_intel_uncore() for that, use it to
avoid the i915_drv.h include.
Since commit 35ec71285c93 ("drm/i915/pc8: Add parent interface for PC8
forcewake tricks"), the compat intel_uncore_forcewake_{get,put} and
FORCEWAKE_ALL macros have become unused. Remove them.
Jani Nikula [Mon, 22 Dec 2025 12:34:00 +0000 (14:34 +0200)]
drm/i915: remove unused dev_priv local variable
Since commit 35ec71285c93 ("drm/i915/pc8: Add parent interface for PC8
forcewake tricks"), the __maybe_unused dev_priv has become definitely
unused. Remove, along with the i915_drv.h include.
Ankit Nautiyal [Tue, 23 Dec 2025 15:08:26 +0000 (20:38 +0530)]
drm/i915/vdsc: Account for DSC slice overhead in intel_vdsc_min_cdclk()
When DSC is enabled on a pipe, the pipe pixel rate input to the
CDCLK frequency and pipe joining calculation needs an adjustment to
account for compression overhead "bubbles" added at each horizontal
slice boundary.
Account for this overhead while computing min cdclk required for DSC.
v2:
- Get rid of the scaling factor and return unchanged pixel-rate
instead of 0.
v3:
- Use mul_u32_u32() for the bubble-adjusted pixel rate to avoid 64x64
multiplication and drop redundant casts in DIV_ROUND_UP_ULL(). (Imre)
Suraj Kandpal [Tue, 23 Dec 2025 06:34:22 +0000 (12:04 +0530)]
drm/i915/cx0: Use the consolidated HDMI tables
Use the consolidated HDMI tables before we try to compute them via
algorithm. The reason is that these are the ideal values and even
though the values calculated via the HDMI algorithm are correct but
not always ideal. This is done for C20 and already exists for C10.
Jani Nikula [Mon, 15 Dec 2025 15:28:29 +0000 (17:28 +0200)]
drm/i915: drop dependency on struct intel_display from i915 initial plane
The i915 core initial plane handling doesn't actually need struct
intel_display for anything. Switch to i915 specific data structures in
i915 core code.
Jani Nikula [Mon, 15 Dec 2025 15:28:21 +0000 (17:28 +0200)]
drm/{i915, xe}: start deduplicating intel_find_initial_plane_obj() between i915 and xe
Move some easy common parts to display. Initially, the
intel_find_initial_plane_obj() error path seems silly, but it'll be more
helpful this way for later changes.
Jani Nikula [Mon, 15 Dec 2025 15:28:18 +0000 (17:28 +0200)]
drm/{i915, xe}: move initial plane calls to parent interface
Add the initial plane handling functions to the display parent
interface. Add the call wrappers in dedicated intel_initial_plane.c
instead of intel_parent.c, as we'll be refactoring the calls heavily.
Jani Nikula [Mon, 15 Dec 2025 15:28:15 +0000 (17:28 +0200)]
drm/i915: move display/intel_plane_initial.c to i915_initial_plane.c
intel_plane_initial.c is i915 specific. Move it to i915 core. Start
renaming stuff with the slightly more natural "initial plane" rather
than "plane initial".
Ville Syrjälä [Thu, 18 Dec 2025 18:20:52 +0000 (20:20 +0200)]
drm/i915/pc8: Add parent interface for PC8 forcewake tricks
We use forcewake to prevent the SoC from actually entering
PC8 while performing the PC8 disable sequence. Hide that
behind a new parent interface to eliminate the naked
forcewake/uncore usage from the display power code.
v2: Mark the interface optional and warn if
someone calls it when not provided (Jani)
Include the header to make sure the extern
declaration matches the definition (Jani)
v3: Rebase due to shuffling
Gustavo Sousa [Tue, 16 Dec 2025 21:12:01 +0000 (18:12 -0300)]
drm/i915/cx0: Toggle powerdown states for C10 on HDMI
A new step has been added to Bspec with respect to the C10 PHY, which
instructs the driver to toggle powerdown value for boths PHY lanes to P0
and then P2 when driving an HDMI connector. This update in the Bspec
reflects the changes required by Wa_14026084006, so document it.
Note that, unlike other display workarounds, this one is actually tied
to the C10 PHY and not to a specific display IP. As such, let's just
document it in intel_cx0_phy.c instead of adding it to
intel_display_wa.c.
Gustavo Sousa [Tue, 16 Dec 2025 21:12:00 +0000 (18:12 -0300)]
drm/i915/cx0: Use a more accurate message for powerdown change failure
We do not use the function intel_cx0_powerdown_change_sequence()
exclusively to take the PHY out of reset, hence the warning message on
failure is misleading. Furthermore, in an upcoming change, we will also
use that function to implement a new C10 PHY workaround.
Use a more accurate message by saying that we failed to change the
powerdown state.
Imre Deak [Mon, 15 Dec 2025 19:23:56 +0000 (21:23 +0200)]
drm/i915/dp: Fail state computation for invalid DSC source input BPP values
There is no reason to accept an invalid minimum/maximum DSC source input
BPP value (i.e a minimum DSC input BPP value above the maximum pipe BPP
or a maximum DSC input BPP value below the minimum pipe BPP value), fail
the state computation in these cases.
Imre Deak [Mon, 15 Dec 2025 19:23:53 +0000 (21:23 +0200)]
drm/i915/dp: Fail state computation for invalid min/max link BPP values
Make sure that state computation fails if the minimum/maximum link BPP
values got invalid as a result of limiting both of these values
separately to the corresponding source/sink capability limits.
Imre Deak [Mon, 15 Dec 2025 19:23:52 +0000 (21:23 +0200)]
drm/i915/dp: Account with pipe joiner max compressed BPP limit for DP-MST and eDP
The pipe joiner maximum compressed BPP must be limited based on the pipe
joiner memory size and BW, do that for all DP outputs by adjusting the
max compressed BPP value already in
intel_dp_compute_config_link_bpp_limits() (which is used by all output
types).
This way the BPP doesn't need to be adjusted in
dsc_compute_compressed_bpp() (called for DP-SST after the above limits
were computed already), so remove the adjustment from there.
projects / thirdparty / kernel / linux.git / log
