Rename the helper updating link configurations to
intel_dp_link_caps_update() to better reflect its functionality.
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-13-imre.deak@intel.com
Move tracking of the link configurations from struct intel_dp to struct
intel_dp_link_caps.
Previous changes moved the helpers operating on configurations to the
link caps module, so the state can now be kept internal to that module.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-12-imre.deak@intel.com
Move the helpers handling link configurations to intel_dp_link_caps.c.
Their functionality is part of the link capability logic and will be
updated to use the link capability state in follow-up changes.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-11-imre.deak@intel.com
Move tracking of the forced link parameters from struct intel_dp to
struct intel_dp_link_caps.
Previous changes made all users access these parameters through the link
caps helpers, so the state can now be kept internal to the link caps
module.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-10-imre.deak@intel.com
Use intel_dp_link_caps_get_forced_params() in the link training fallback
code instead of directly accessing the state. This allows the link caps
module to track changes to forced parameters internally.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-9-imre.deak@intel.com
Move the debugfs entries for the forced and max DP link parameters to
intel_dp_link_caps. Their functionality is part of the link capability
logic and will be updated to use the link capability state in follow-up
changes.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-8-imre.deak@intel.com
Simplify querying the forced link rate and lane count by
performing the zero checks inside the helpers, allowing callers
to use the returned values directly.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-7-imre.deak@intel.com
Move the helpers handling forced link parameters to intel_dp_link_caps.c.
Their functionality is part of the link capability logic and will be
updated to use the link capability state in follow-up changes.
Return the forced link rate and lane count through a
struct intel_dp_link_config, which is the canonical way the rest of the
link capability API will also accept and return link configurations.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-6-imre.deak@intel.com
Move the helpers handling common link rates to intel_dp_link_caps.c.
Their functionality is part of the link capability logic and will be
updated to use the link capability state in follow-up changes.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-5-imre.deak@intel.com
Start isolating the DP link capability logic from the generic DP code by
adding a separate intel_dp_link_caps module and a corresponding state
object.
Allocate the state so it can remain opaque within its module.
Follow-up changes will move link capability helpers and state from
intel_dp.c and intel_dp_link_training.c to the new module and state.
v2: Remove unnecessary function documentation. (Jani)
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-4-imre.deak@intel.com
Add a struct representing the public unpacked format of a link
configuration. This will be used by the DP link capability API added
as a follow-up, and by DP code in general that needs to track a link
configuration.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-3-imre.deak@intel.com
Rename intel_dp_link_config to intel_dp_link_config_entry to prepare
for tracking a link configuration in both an internal packed and a
public unpacked format. A follow-up change will add
struct intel_dp_link_config representing the public unpacked format.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260616200849.3534628-2-imre.deak@intel.com
Adjust the panel fixed mode selection algorithm to only consider
fixed modes that are "VRR compatible" with the old fixed mode
when userspace doesn't want to allow full modesets. This will
allow a VRR based refresh rate changes (ie. just a change in
the vblank length) via the fastset path.
When full modesets are allowed, we still use the original algorithm
as that may pick a fixed mode with a more optimal dotclock, potentially
leading to reduced power consumption.
This approach works as long as userspace does the initial
allow_modeset=true commit using the highest refresh rate it will
want to use. Subsequent commits with allow_modeset=false can then
switch between lower refresh rates without blinks.
One remaining hurdle we may need to solve is the guardband length.
Assuming the highest refresh rate vblank is too short for
intel_vrr_compute_optimized_guardband() the intitial guardband will
match the highest refresh rate vblank. A subsequent switch to a lower
refresh rate will then recompute the guardband and select a value
that is higher (since the vblank will be longer). The mismatch in
guardband lengths will prevent the fastset. We may either have to
preserve the original (sub-optimal) guardband, or we'll have to
revisit the idea of changing the guardband without a full modeset.
Note that I'm not 100% happy with this solution because
intel_panel_fixed_mode() is no longer fully idempotent, but I wasn't
able to come up with anything truly better either :/ The simple
solution would be just to always pick the fixed mode with the highest
dotclock, but that could lead to increased power consumption even
when high refresh rates are never used.
Perhaps the proper solution would be to just deprecate this
idea of taking in random modes for internal panels and then
cooking up a compatible fixed modes. Life would be easier if
userspace was required to provide the desired fixed mode directly.
But in order to do that we'd need to introduce new uapi properties
to control the pfit aspect of this, and we'd probably need a new
client cap to select between the old and new userspace behaviour.
Something to consider in the future...
v2: Rebase due to earlier changes to VRR fixed mode selection
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260622213602.7244-6-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Pass the full atomic state to intel_panel_compute_config(). We'll
need this for some upcoming VRR fastset tricks. And to accompany
full state we'll also need the crtc (or its state) as well.
v2: Rebase
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260623114130.7333-1-ville.syrjala@linux.intel.com
Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Upcoming changes will need access to the full atomic state
in .compute_config(). Pass it in from the top.
Couple of the implementations already dug this out via the
crtc_state/conn_state->state pointer, but we don't want to
use that anywhere because it's a bit of a footgun by only
being valid during the early stages of the commit.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260622213602.7244-4-ville.syrjala@linux.intel.com
Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Add a new mode matching flag DRM_MODE_MATCH_TIMINGS_VRR. This is
identical to DRM_MODE_MATCH_TIMINGS, except it requires the vsync
pulse to remain anchored to the end of vtotal, as opposed to the
start of the frame. VRR capable hardware can therefore treat
matching modes as just variants of the same mode with a different
vblank lengths.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260622213602.7244-3-ville.syrjala@linux.intel.com
Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Split the VRR vs. fixed refresh rate fixed mode selection into two
completely separate stages. First try the VRR method, which will
only accept fixed modes that are in the VRR range and whose refresh
rate is equal or higher to the user's requested mode's refresh rate.
If the VRR method doesn't find anything we fall back to the fixed
refresh rate method of simply looking for the fixed mode with the
closest refresh rate to the user's request.
The main benefit is that we will only perform the VRR vtotal adjustment
on fixed modes that have equal or higher refresh rate to the user's
requested mode, thus we will never end up in a situation where we'd
have to shrink the fixed mode's vtotal. This avoids any risk of ending
up with a vtotal that is too short.
v2: Drop redundant intel_panel_fixed_mode() call (Ankit)
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260623114035.7185-1-ville.syrjala@linux.intel.com
Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Store tiling function pointer in struct intel_panic instead of struct
intel_framebuffer, and store struct intel_panic pointer instead of
struct intel_framebuffer pointer in struct drm_scanout_buffer private
member.
To make this happen, pass the tiling function pointer to panic setup
hook, and initialize sb->private in the hook for clarity.
This allows us to drop the dependency on struct intel_framebuffer from
i915 and xe panic code.
Note: It would be less verbose to have a typedef for the tiling function
pointer. However, there isn't a nice location for it that wouldn't also
increase header interdependencies.
Cc: Jocelyn Falempe <jfalempe@redhat.com>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/d97abae79db3437c617cd4cb6193ba017b3a8d78.1780394867.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Bspec has been updated for xe2_lpd+ platforms on how to handle
the bw buddy programming in case no matching memory configuration
is found w.r.t the current page mask table. The recommendation
is to keep the default settings for the related registers as it
is without explicitly disabling the bw buddy.
v2: removed extra explanation
v3: fixed typo in commit message
Bspec: 68871
Suggested-by: Ville Syrjala <ville.syrjala@intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/20260616184131.295013-1-vinod.govindapillai@intel.com
When the VRR timing generator is always used, the hardware behaves
as VRR-active regardless of crtc_state->vrr.enable.
The DSB paths that depend on the VRR safe window therefore need to follow
the VRR code paths in that case too:
- dsb_chicken(): program the SAFE_WINDOW chicken bits,
- intel_dsb_vblank_evade(): use vmin/vmax vblank starts for the
wait window,
- intel_dsb_wait_for_delayed_vblank(): wait inside the vmin safe window
before the scanline-based delayed vblank wait.
Introduce helper pre_commit_use_safe_window() and use it in the three sites
v2: Instead of modifying pre_commit_is_vrr_active() use a new helper and
use it only in the required places. (Ville).
v3: -Keep using pre_commit_is_vrr_active() for DCB path. (Ville)
-Add a separate check for fixed RR with VRR TG and use
fixed mode vblank start there. (Ville)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260617051417.2223526-1-ankit.k.nautiyal@intel.com
In intel_dsb_wait_for_delayed_vblank() the VRR path issues a
WAIT_DSL_OUT(safe_window_start, vmin_safe_window_end) followed by a
WAIT_USEC for SCL+1 scanlines to land on the delayed vblank.
Experimentally, DSB appears to observe a slightly stale PIPEDSL value.
When the actual scanline has just reached safe_window_start, the DSB
may still see a value at or before that boundary when WAIT_DSL_OUT is
evaluated, causing the wait to complete immediately.
As a result, the subsequent WAIT_USEC executes too early, and the
flip-done interrupt fires roughly one frame ahead of the delayed vblank.
Shift the scanline start back by one to ensure the wait window is
entered reliably.
v2: Replace explicit one-scanline delay with scanline boundary
adjustment (safe_window_start - 1). (Ville)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260608123711.1121908-2-ankit.k.nautiyal@intel.com
Turns out both CDCLK_CTL pipe select 0b110 (what Bspec lists for
pipe C on ICL) and 0b100 (what BSpec lists for pipe C on TGL+)
actually select pipe C on ICL. So we can get rid of the weird
ICL special case and just use the simpler TGL+ definition of
the pipe select bits.
This was reverse engineered with a hacked up intel_display_poller.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260612173653.7830-7-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Currently bxt_sanitize_cdclk() assumes that
bxt_cdclk_cd2x_pipe(INVALID_PIPE) gives us the full mask for
for the relevant bitfield. While that is true, it does make the
code a bit confusing to read. Introduce bxt_cdclk_cd2x_pipe_mask()
to make the situation a bit less confusing.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260612173653.7830-6-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Document which CDCLK_CTL bits are relevant for which platforms.
Saves me from having to look this up in the spec every time.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260612173653.7830-5-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Make debugging a bit easier by printing out the specific reason
for the CDCLK sanitization. Currently one is forced to guess what
is actually happening.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260612173653.7830-3-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
The GOP (and even Bspec on some platforms) is a bit inconsistent
on what the CDCLK_FREQ_DECIMAL divider should be. Currently any
mismatch there causes a full CDCLK PLL disable+re-enable, which
we really don't want to do if any displays are currently active.
Let's instead just reprogram CDCLK_FREQ_DECIMAL when that is the
only thing amiss. For any other (more serious) mismatch we still
punt to the full PLL reprogramming.
We also need to tweak the bxt_cdclk_cd2x_pipe() stuff a bit to
consistently select pipe==NONE since we have no idea which pipes
are enabled at this point. Since we're not actually changing the
CDCLK frequency here we don't need to sync the update to any
pipe.
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16209
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260612173653.7830-2-ville.syrjala@linux.intel.com
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
With optimized guardband, we need to take into account LOBF requirements
via intel_alpm_lobf_min_guardband().
Currently, we set has_lobf based not only on whether it is supported, but
also on whether PSR/fixed RR are ON. Since these features can switch ON and
OFF seamlessly, this may cause LOBF to change, resulting in a change in
guardband requirements, and eventually to a full modeset.
To avoid this, always account for LOBF if it is supported, in the
encoder->compute_config() stage. For this, allow has_lobf to be set
irrespective of PSR/Fixed RR. Later, in the encoder->compute_config_late()
stage, use the PSR/Fixed RR checks to set has_lobf to the final value.
Move the PSR/Fixed RR checks from intel_alpm_lobf_compute_config() to
intel_alpm_lobf_compute_config_late(), where we already account for other
LOBF constraints.
v2: Reset has_lobf if psr or VRR is ON in
intel_alpm_lobf_compute_config_late(). (Animesh)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260616080627.2136659-1-ankit.k.nautiyal@intel.com
intel_cx0_phy_check_hdmi_link_rate does not exist but is still
declared. Remove it.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260617041807.162927-1-suraj.kandpal@intel.com
There are monitors being sensitive to MSA and end up
blanking out when we override Vtotal, DP transcoder
uses TRANS_VTOTAL to derive MSA VTotal. Avoid overriding
crtc_vtotal to 1 on platform which supports VRR Timing
generator and always program VTOTAL from mode timing in
transcoder timing paths.
--v2:
- Remove write to crtc_state->hw.adjusted_mode.crtc_vtotal
during intel_vrr_get_config. (Ankit)
- Fix merge conflicts.
Bspec: 70001
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
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/20260617045850.862100-1-mitulkumar.ajitkumar.golani@intel.com
The DC_STATE_EN register has read-only status bits that are set by
hardware on some platforms. These bits may cause the read-back
verification loop in gen9_write_dc_state() to spuriously retry.
Mask the RO bits from the read-back comparison to prevent
unnecessary retries.
Changes in v2:
- Rename patch from
"drm/i915/display: Use rmw in gen9_write_dc_state() to preserve non-DC
bits"
to
"drm/i915/display: Mask RO bits in gen9_write_dc_state()"
- Mask only RO bits rather than masking all non DC state bits
in DC_STATE_EN. As the register has also some clear-on-write flags,
like 'Display DC*CO State Status DSI'(Imre Deak)
Changes in v3:
- Limit ro mask to read-back comparison.
Changes in v4:
- Add bit definitions (Jani Nikula)
BSpec: 49437,69115
Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260605155359.4116572-1-dibin.moolakadan.subrahmanian@intel.com
Enable DC3CO mask in get_allowed_dc_mask().
Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260616162154.2630995-17-dibin.moolakadan.subrahmanian@intel.com
Check if DC3CO is allowed before calling CMTG
functions in intel_atomic_commit_tail() as CMTG is only used
by DC3CO DC state.
Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260616162154.2630995-16-dibin.moolakadan.subrahmanian@intel.com
Expose DC3CO count and residency for xe3lp platforms via debugfs.
Changes in v2:
- Keep dc5_reg register initialization to avoid any
invalid access (sashiko)
Changes in v3:
- Change XE3P_DMC_DC3CO_COUNT address to lower case (Manna Animesh).
Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260616162154.2630995-15-dibin.moolakadan.subrahmanian@intel.com
Add xe3lpd_enable_dc_count() to enable the DC_COUNT_EN register.
Also define DC_STATE_DC3CO_RESIDENCY to read DC3CO residency.
Needed to retrieve DC residency for DC3CO.
v2:
- Add a guard to xe3lpd_enable_dc_count() instead of relying
on caller. [Animesh]
Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260616162154.2630995-14-dibin.moolakadan.subrahmanian@intel.com
For DC3CO, idle_frames is programmed to 0, so PSR does not
enter deep sleep. Add delayed work to schedule DC3CO exit
after an idle duration derived from frame time (minimum
equivalent of 6 frames).
The work is re-armed from the PSR flush path on relevant frontbuffer
activity. Once the display remains idle, DC3CO is disabled, idle frames
are reprogrammed to their normal value, and DC6 is enabled to allow
deeper power savings.
Changes in v2:
- Squash "PSR set idle frames while exit from DC3CO"
into this patch (Uma Shankar)
- Add cancel_delayed_work() in intel_psr_disable_locked()
before clearing dc3co_eligible (Uma Shankar)
Changes in v3:
- Re-arm cancelled DC3CO work in psr resume
- Schedule DC3CO work from intel_psr_post_plane_update(). This is to
make sure DC3CO work scheduling will happen even without psr flush,
which may be a valid scenario.
Changes in v4:
- Remove unused function parameter enum fb_op_origin origin
that is never used in the function body. (Animesh)
Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260616162154.2630995-13-dibin.moolakadan.subrahmanian@intel.com
Add PR_ALPM_CTL_USE_DC3CO_IDLE_PROTOCOL bit definition and set it
when DC3CO is allowed.
Changes in v2:
- Squash "Define DC3CO idle protocol bit in PR_ALPM_CTL"
into this patch (Uma Shankar)
- Use intel_display_power_dc3co_allowed(display)
instead of intel_dc3co_allowed(state)
Changes in v3:
- check only intel_display_power_dc3co_allowed()
before wiriting PR_ALPM_CTL_USE_DC3CO_IDLE_PROTOCOL (Jani Nikula)
BSpec: 75253
Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260616162154.2630995-12-dibin.moolakadan.subrahmanian@intel.com
Force idle_frames to 0 when DC3CO is eligible.
Changes in v2:
- Extend existing Wa_16025596647 condition
instead of adding a new if block (Uma Shankar)
BSpec: 75253
Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260616162154.2630995-11-dibin.moolakadan.subrahmanian@intel.com
Store DC3CO eligibility in intel_dp->psr during
intel_psr_post_plane_update() so PSR configuration
can take DC3CO into account.
This will be used to control PSR2 parameters such as idle frames.
Changes in v2:
- Use intel_display_power_dc3co_allowed(display) instead
of intel_dc3co_allowed(state)
Changes in v3:
- Update psr.dc3co_eligible before
intel_psr_enable_locked() call (sashiko)
Changes in v4:
- rename eligible to allowed (Jani Nikula)
Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260616162154.2630995-10-dibin.moolakadan.subrahmanian@intel.com
Compute if dc3co is allowed in intel_atomic_commit_tail()
based on pipe/port constraints and runtime triggers and store
result in display->power.dc3co.
When DC3CO can be enabled, request DC_STATE_EN_UPTO_DC3CO and
reduce the DC entry delay. Otherwise, retain the existing
delay and set default DC_STATE_EN_UPTO_DC6.
Changes in v2:
- Move DC3CO compute logic from intel_atomic_check()
to intel_atomic_commit_tail as it is not advisable to
change persistent state in atomic check (Jani Nikula)
- Add psr2 deep sleep check in dc3co compute.
- Move allowed computation logic inside dc3co update (Jani Nikula).
- Add dc3co support check in dc3co allowed function (Jani Nikula)
- Move all dc3co functions to intel_display_power.c and
rename functions accordingly (Jani Nikula)
- Clean up dc3co/dc6 power async delay in
intel_atomic_commit_tail() (Jani Nikula)
Changes in v3:
- Remove debug print from intel_display_power_dc3co_update()
BSpec: 75253
Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260616162154.2630995-9-dibin.moolakadan.subrahmanian@intel.com
Add intel_psr2_in_deep_sleep() to check whether PSR2 is currently in
DEEP_SLEEP state. Will be used in subsequent patches.
Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260616162154.2630995-8-dibin.moolakadan.subrahmanian@intel.com
Add intel_display_power_dc3co_supported() helper to query DC3CO
support from allowed_dc_mask.
Changes in v2:
- Add HAS_DC3CO() check to intel_display_power_dc3co_supported().
Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260616162154.2630995-7-dibin.moolakadan.subrahmanian@intel.com
Add HAS_DC3CO() to identify platforms supporting DC3CO.
DC3CO is supported from display version 35 onwards.
BSpec: 75253
Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260616162154.2630995-6-dibin.moolakadan.subrahmanian@intel.com
Add DC3CO handling to the dc_off power well sequencing and disable the
DMC wakelock when exiting DC3CO.
Changes in v2:
- Call assert_can_enable_dc3co() before dc3co enable (Manna Animesh)
BSpec: 75253
Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260616162154.2630995-5-dibin.moolakadan.subrahmanian@intel.com
