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
Add DG2-specific DPLL manager infrastructure for MPLLB-backed port PLLs.
Introduce PLL id mapping, DG2-specific DPLL callbacks for
enable/disable/readout/frequency calculation, and manager callbacks
for compute/get/dump/compare. The platform is not switched over yet.
DG2's PLL-to-encoder lookup prefers the active encoder using the PLL,
but fall back to a matching encoder for the fixed port-to-PLL mapping
when no active user can be identified.
This keeps the active-user fix for operational paths while allowing
readout and verification paths to resolve the PHY even when
pll->active_mask does not identify an active user.
v2: Use intel_encoder_is_dig_port() to filter out
MST virtual encoders (Imre)
Assisted-by: Copilot:claude-sonnet-4-6
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> (v1)
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://patch.msgid.link/20260630115336.1059976-3-mika.kahola@intel.com
Refactor the DG2 MPLLB enable path by splitting out a helper that
programs the PHY directly from an intel_mpllb_state.
This is preparatory work for moving DG2 MPLLB handling under the DPLL
framework, where callbacks operate on dpll_hw_state rather than the
full crtc_state.
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-2-mika.kahola@intel.com
Set crtc_state->vrr.cmrr.enable at the end of
intel_vrr_cmrr_compute_config() so that CMRR is actually enabled once
the M/N parameters have been computed. This is the final step that
turns on CMRR, with all the parameter computation handled in the
earlier patches.
--v2:
- Everything else except enable compute to handle before this patch
(Chaitanya)
--v3:
- Remove redundant return from compute config
--v4:
- Update CMRR commit message (Chaitanya)
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@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/20260730105919.3913412-11-mitulkumar.ajitkumar.golani@intel.com
Move the CMRR M/N register writes into a new
intel_vrr_set_cmrr_timings() helper called from
intel_vrr_set_fixed_rr_timings(), so CMRR is programmed together with
the fixed rr timings for both the CMTG and CPU transcoder, instead of
being open-coded in intel_vrr_set_transcoder_timings(). Drop the
now-unused cmrr_enable argument to intel_vrr_tg_enable().
No functional change intended for non-CMRR configurations.
--v2:
- Commit message changes.
- Added Simplified enable/disable sequence. (Chaitanya)
--v3:
- Guard CMRR enable condition (Chaitanya)
- Comment changes updated (Chaitanya)
- Squash register write commits together and
avoid double writing issue. (Chaitanya)
--v4:
- Guard CMRR enable/disable with platform check
--v5:
- Update CMRR in enable/disable path
--v6:
- Simplify enable/disable calls (Chaitanya)
- Make function usable for common cmtg and cpu transcoder
(Chaitanya)
--v7:
- Update commit message (Chaitanya)
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Assisted-by: Claude:claude-opus-4-8
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260730105919.3913412-9-mitulkumar.ajitkumar.golani@intel.com
Writing the per-CRTC "intel_vrr_target_refresh_rate" debugfs file only
updates crtc->force_cmrr, a side channel that is not tracked by the
atomic state. The requested ratio therefore does not reach the hardware
until some unrelated commit recomputes the pipe config.
Kick an internal atomic commit for the CRTC from the debugfs write and
mark the CRTC mode as changed so the pipe config is recomputed.
Note that this commit may or may not be downgraded to a fastset,
depending on whether the computed vblank value (with LRR disabled)
changes, so it is not characterised as a fastset.
If the commit fails, restore the previous numerator/denominator so that
force_cmrr does not hold on to bad values, which would otherwise make
all subsequent commits fail.
--v2:
- Commit message and code comment update (Chaitanya)
- Commit header update
- Restore to old known debugfs values when commit fails
(Chaitanya)
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@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/20260730105919.3913412-8-mitulkumar.ajitkumar.golani@intel.com
Rework the fractional CMRR computation into a generic,
transcoder-agnostic helper driven by an explicit per-CRTC debugfs
target, replacing the previous disabled, eDP-only code path. Compute
CMRR_M and CMRR_N timings based on the video mode requirements. A 1:1
ratio (denominator == 1000) means no video timing is required. Note
that the CMRR enable path is wired up separately; this patch only lays
down the generic computation.
Remove computation of mode_flags, I915_MODE_FLAG_VRR, as CMRR is
being moved to the fixed refresh rate path. Also return early from
the CMRR computation if the existing computation is already sufficient.
--v2:
- Derive video_mode locally instead of caching it in the persistent
struct intel_crtc state (Jani, Chaitanya)
- Fix numerator unit in comment: milli-Hz, not kHz (Chaitanya)
- Fix "requirement" typo and clarify that CMRR is not yet enabled in
the commit message (Chaitanya)
- Fix precision issue while computing the M/N ratio (Chaitanya)
- Rename multiplier_m and multiplier_n to improve readability
(Chaitanya)
- Compute vtotal as it is required for dithering as per the algorithm
implementation (Chaitanya)
- Replace the misleading adjusted_pixel_rate with dividend, which is
more descriptive
--v3:
- Mention the rationale for not computing I915_MODE_FLAG_VRR
(Chaitanya)
- Remove the redundant return statement at the end of the CMRR
computation (Chaitanya)
- Correct cmrr_n calculation (Chaitanya)
- Add an early return if the current computation is already sufficient
to drive the mode without CMRR (Chaitanya)
- Round up requested_refresh_rate (Validation)
- Fix integer overflow
--v4:
- Update cmrr_n calculation to avoid aggressive dithering
- Use div64_u64 to truncate to the floor value instead of
DIV_ROUND_UP_ULL, which rounds up to the ceiling value
- Add a TODO comment to the cmrr_n calculation
- Add a condition for custom refresh rate requests
- Update the CMRR computation comment block in compute_config
--v5:
- Simplify computation
- Correct typo in commit message (Chaitanya)
- Compute early return condition (Chaitanya)
--v6:
- Simplify commit message
- Simplify video timing requirement compute function (Chaitanya)
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@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/20260730105919.3913412-7-mitulkumar.ajitkumar.golani@intel.com
