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.
--v2:
- Call during intel_update_crtc.(Ankit)
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-11-mitulkumar.ajitkumar.golani@intel.com
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)
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-10-mitulkumar.ajitkumar.golani@intel.com
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.
v2: Rephrased commit message. (Ankit)
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-9-mitulkumar.ajitkumar.golani@intel.com
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)
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-8-mitulkumar.ajitkumar.golani@intel.com
Add DC Balance params to crtc_state, also add state checker
params for related properties.
--v3:
- Seggregate crtc_state params with this patch. (Ankit)
--v4:
- Update commit message and header. (Ankit)
- Add +1 to VMIN and VMAX only when it is non-zero. (Ankit)
--v5:
- Add headers in sorted order. (Jani Nikula)
--v6:
- Add a separate function to get and check dc_balance params.
- Avoid repeatative use of MMIO read. (Ankit)
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-6-mitulkumar.ajitkumar.golani@intel.com
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)
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-5-mitulkumar.ajitkumar.golani@intel.com
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)
--v9:
- Remove comment. (Ankit)
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-4-mitulkumar.ajitkumar.golani@intel.com
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.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20251219060302.2365123-7-ankit.k.nautiyal@intel.com
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.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20251219060302.2365123-6-ankit.k.nautiyal@intel.com
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)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20251219060302.2365123-5-ankit.k.nautiyal@intel.com
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)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20251219060302.2365123-4-ankit.k.nautiyal@intel.com
GVT code uses macros for register offsets that require display internal
structures. This makes clean separation of display code and
modularization difficult.
Introduce APIs to abstract offset calculations:
- intel_display_device_pipe_offset()
- intel_display_device_trans_offset()
- intel_display_device_cursor_offset()
- intel_display_device_mmio_base()
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)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com> (#v1)
Link: https://patch.msgid.link/20251219060302.2365123-3-ankit.k.nautiyal@intel.com
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)
Suggested-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20251219060302.2365123-2-ankit.k.nautiyal@intel.com
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.
v2: Rebase
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/44a5d526a097ab9276e60162263fa8cd23325ce7.1766406794.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Use static inline instead of macro for
intel_uncore_arm_unclaimed_mmio_detection() to avoid the need for
__maybe_unused annotations.
v2: Rebase, intel_uncore_arm_unclaimed_mmio_detection()
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> # v1
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/7ddee71952315e70e4a7df23638100b664e293bd.1766406794.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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)
Bspec:68912
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251223150826.2591182-1-ankit.k.nautiyal@intel.com
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.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20251223063422.1444968-1-suraj.kandpal@intel.com
With the i915 switch to generic fault injection, display no longer needs
the compat i915_utils.h. Remove it, along with a few includes.
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/20251219104036.855258-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Move intel_reuse_initial_plane_obj() into common display code, and split
the ->find_obj hook into ->alloc_obj and ->setup hooks.
Return the struct drm_gem_object from ->alloc_obj in preparation for
moving more things to display.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/c71011dbb11afaa5c4da30aa2627833374300d63.1765812266.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/ab91c891677fe2bb83bf5aafa5ee984b2442b84d.1765812266.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
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
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251218182052.18756-1-ville.syrjala@linux.intel.com
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.
Bspec: 64568, 74489
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Link: https://patch.msgid.link/20251216-wa_14026084006-c10-hdmi-toggle-powerdown-v1-2-08677b03e2f1@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
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.
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Link: https://patch.msgid.link/20251216-wa_14026084006-c10-hdmi-toggle-powerdown-v1-1-08677b03e2f1@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
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.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-17-imre.deak@intel.com
There is no reason to accept an invalid maximum sink compressed BPP
value (i.e. 0), fail the state computation in this case.
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/20251215192357.172201-16-imre.deak@intel.com
There is no reason to accept a minimum/maximum link BPP value above the
maximum throughput BPP value, fail the state computation in this case.
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/20251215192357.172201-15-imre.deak@intel.com
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.
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/20251215192357.172201-14-imre.deak@intel.com
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.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-13-imre.deak@intel.com
A DSC compressed stream requires FEC (except for eDP), which has a BW
overhead on non-UHBR links that must be accounted for explicitly. Do
that during computing the required BW.
Note that the overhead doesn't need to be accounted for on UHBR links
where FEC is always enabled and so the corresponding overhead is part of
the channel coding efficiency instead (i.e. the overhead is part of the
available vs. the required BW).
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-12-imre.deak@intel.com
On MST links the symbol alignment and SSC have a BW overhead, which
should be accounted for when calculating the required stream BW, do so
during mode validation for an uncompressed stream.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-11-imre.deak@intel.com
Use intel_dp_effective_data_rate() to calculate the required link BW for
compressed streams on non-UHBR DP-SST links. This ensures that the BW is
calculated the same way for all DP output types and DSC/non-DSC modes,
during mode validation as well as during state computation.
This approach also allows for accounting with BW overhead due to DSC,
FEC being enabled on a link. Acounting for these will be added by
follow-up changes.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-10-imre.deak@intel.com
