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.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-21-imre.deak@intel.com
intel_edp_dsc_compute_pipe_bpp() matches now
intel_dp_dsc_compute_pipe_bpp(), remove the former function.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-20-imre.deak@intel.com
Move computing the eDP compressed BPP value to the function computing
this for DP, allowing further simplifications later.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-19-imre.deak@intel.com
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.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-18-imre.deak@intel.com
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.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-17-imre.deak@intel.com
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.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-16-imre.deak@intel.com
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.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-15-imre.deak@intel.com
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.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-14-imre.deak@intel.com
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).
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-13-imre.deak@intel.com
Factor out compute_max_compressed_bpp_x16() also used during mode
validation in a follow-up change.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-12-imre.deak@intel.com
Factor out compute_min_compressed_bpp_x16() also used during mode
validation in a follow-up change.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-11-imre.deak@intel.com
Prepare for follow-up changes using dsc_throughput_quirk_max_bpp_x16()
without an intel_crtc_state pointer.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-10-imre.deak@intel.com
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.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-9-imre.deak@intel.com
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.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-8-imre.deak@intel.com
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.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-7-imre.deak@intel.com
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.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-6-imre.deak@intel.com
Factor out align_max_vesa_compressed_bpp_x16(), also used later for
computing the maximum DSC compressed BPP limit.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-5-imre.deak@intel.com
Factor out align_max_sink_dsc_input_bpp(), also used later for computing
the maximum DSC input BPP limit.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-4-imre.deak@intel.com
Drop the unused timeslots parameter from dsc_compute_link_config() and
other functions calling it.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-2-imre.deak@intel.com
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: ba391a102e ("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>
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.
v2:
- Add missing "val |= " when calling bxt_cdclk_cd2x_pipe().
(Dnyaneshwar)
Bspec: 68864, 69090
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Link: https://patch.msgid.link/20260106-xe3_lpd-no-cd2x-divider-v2-1-06e5cbc9dabb@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
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: 741eeabb7c ("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>
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.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260105055937.136522-3-suraj.kandpal@intel.com
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.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260105055937.136522-2-suraj.kandpal@intel.com
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.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260105055937.136522-1-suraj.kandpal@intel.com
intel_display_limits.c was never supposed to be added. Remove it.
Fixes: f3255cf449 ("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>
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.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/f40a1fd365cbcfb77bd76ce0041c4523699f6052.1767009044.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/dce86cb031d523a95a96ed2bf9c93bb28e6b20ab.1767009044.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20251223104542.2688548-19-mitulkumar.ajitkumar.golani@intel.com
Pause the DMC DC Balancing for the remainder of the
commit so that vmin/vmax won't change after we've baked
them into the DSB vblank evasion commands.
--v2:
- Remove typo. (Ankit)
- Separate vrr enable structuring. (Ankit)
--v3:
- Add gaurd before accessing DC balance bits.
- Remove redundancy checks.
--v4:
- Move events to separate function.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20251223104542.2688548-17-mitulkumar.ajitkumar.golani@intel.com
Add function to control DC balance enable/disable bit via DSB.
--v2:
Remove redundant forward declaration.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20251223104542.2688548-16-mitulkumar.ajitkumar.golani@intel.com
After VRR Push is sent, need to wait till flipline decision boundary
to get Push bit to get cleared.
--v2:
- Adjust delays to vrr vmin vblank delays. (Ankit)
--v3:
- Change intel_vrr_vmin_safe_window_end() so that
intel_dsb_wait_for_delayed_vblank() uses correct delay. (Ankit)
--v4:
- Simplify intel_vrr_vmin_safe_window_end implementation. (Ankit)
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20251223104542.2688548-15-mitulkumar.ajitkumar.golani@intel.com
