In preparation for always passing struct intel_display to
for_each_intel_crtc*() family of iterators, start off by unifying their
usage to always having struct intel_display *display around, and passing
display->drm to them.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/447a5b2309e213abb849601727d45b406d440c88.1778659089.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
xe_display_flush_cleanup_work() is a bit of an oddball function in xe
display code. There shouldn't be anything this specific or xe
specific. While I'm not sure what the correct refactor for the function
should be, move it to shared display code for starters, next to the
eerily similar but slightly different intel_has_pending_fb_unpin() that
is only called from i915 core.
The main goal here is to unblock some refactors on
for_each_intel_crtc().
v2: Add FIXME comment (Ville)
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260525110553.651208-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The i915 and xe calls to display, in particular for
probe/cleanup/suspend/resume, need to be unified. It does not help to
have the related calls scattered around. As a small step forward,
relocate the intel_hpd_cancel_work() call from intel_irq_uninstall() to
i915_driver_remove().
Note that the other intel_irq_uninstall() call sites don't need the
call, as they're on error paths where hotplug hasn't been enabled yet.
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/20260516101852.1373108-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Detect DPRX capability changes without a long HPD or RX_CAP_CHANGED
signal and queue a corresponding link params reset.
Besides detecting the above unexpected capability changes, this also
avoids races between queuing and handling a deferred link params reset.
v2: (Ville)
- Query/set intel_dp::reset_link_params instead of using helpers for
these.
- Assert matching types for old/new common rate elements as well.
- Add TODO: for adding a struct tracking both rates and number of rates.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260522160514.2628249-5-imre.deak@intel.com
Cache the maximum common lane count together with the common link
rates.
This is safe because the cached value is updated:
- during driver probe, before the connector is registered and can be
used for mode validation or modesetting
- during resume, before output HW state readout can query it
- during connector detection, right after updating the sink/link
capabilities
Caching the value allows detecting max common lane count changes in
a follow-up change and keeps the tracking of max common lane count
aligned with that of common rates.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260522160514.2628249-4-imre.deak@intel.com
Add intel_dp_set_common_link_params() to prepare for updating the
maximum common lane count together with the common rates.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260522160514.2628249-3-imre.deak@intel.com
There is no reason to distinguish between DPRX capability changes
signaled via a long HPD and via an RX_CAP_CHANGED HPD IRQ.
Both cases result in reading out the DPRX capabilities and updating the
corresponding sink and common capabilities cached in intel_dp, however
only the long HPD resets the link training/recovery state and MST link
probe parameters correspondingly. The link training/recovery state may
contain reduced maximum link rate/lane count values left over from a
previous link training failure.
Based on the above after an RX_CAP_CHANGED increased the link rate, lane
count parameters the maximum link rate/lane count in the link
training/recovery state may remain below these, leaving the newly added
valid configurations unavailable for subsequent modesets in an
inconsistent way.
Handle RX_CAP_CHANGED IRQs the same way as long HPDs and reset the link
recovery state and MST link probe parameters in that case as well.
v2: Set intel_dp::reset_link_params instead of using a helper for this.
(Ville).
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260522160514.2628249-2-imre.deak@intel.com
For Legacy timing generator, if there are no panel replay/sel_update or
other SRD constraints, the Set context latency (SCL) window should be
at least 1.
However, for VRR timing generator the SCL window can be 0. It has other
guardband constraints, but that are checked during guardband computation.
Allow SCL to be 0 for platforms that have VRR TG always on.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20260517142753.2813959-3-ankit.k.nautiyal@intel.com
'needs_sel_update' is common for both display version branches, so check it
once and keep the version specific checks as separate early returns.
v2: Split into separate early returns. (Jani)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20260517142753.2813959-2-ankit.k.nautiyal@intel.com
Since Lunarlake there is no restriction planar planes has to be even
positions. Due to this we may end up having odd offset for UV-plane in
selective fetch configuration. Add handling for this case into selective
fetch configuration.
Bspec: 68927
Suggested-by: Vidya Srinivas <vidya.srinivas@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Vidya Srinivas <vidya.srinivas@intel.com>
Link: https://patch.msgid.link/20260512080022.2527094-1-jouni.hogander@intel.com
We are observing following warnings:
*ERROR* power well DC_off state mismatch (refcount 0/enabled 1)
gen9_dc_off_power_well_enabled is considering target state DC_STATE_DISABLE
as DC_OFF power well being enabled. Fix this by using wakeref for the
purpose.
To achieve this we need to modify notification code as well. Currently it
is possible that PSR gets notified vblank enable/disable twice on same
status. This is currently not a problem as it is just triggering call to
intel_display_power_set_target_dc_state with same target state as a
parameter. When using wakeref this becomes a problem due to reference
counting. Fix this storing vbank status on last notification and use that
to ensure there are no more than one notification with same vblank status.
v2: ensure there is no subsequent notifications with same status
Fixes: aa451abcff ("drm/i915/display: Prevent DC6 while vblank is enabled for Panel Replay")
Cc: <stable@vger.kernel.org> # v6.13+
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/20260520104944.239797-2-jouni.hogander@intel.com
Currently we are blocking DC states only when Panel Replay is enabled on
vblank enable. It may happen that Panel Replay is getting enabled when
vblank is already enabled. Fix this by blocking DC states always if Panel
Replay is supported.
While at it take care of possible dual eDP case by looping all encoders
supporting PSR.
Fixes: 0c427ac78a ("drm/i915/psr: Add interface to notify PSR of vblank enable/disable")
Cc: <stable@vger.kernel.org> # v6.16+
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/20260520104944.239797-1-jouni.hogander@intel.com
Commit 792d2b9a12 ("drm: drop mtrr from i915"), added this comment,
drop it since it since MTRR no longer exists since 2013 and is removed
by commit 281856477c ("drm: rip out drm_core_has_MTRR checks").
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260522104548.980226-1-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Gen9 platforms allow CRTC's to be programmed with a background/canvas
color below the programmable planes. Let's expose this as a property to
allow userspace to program a desired value.
This patch is based on earlier work by Chandra Konduru and Matt Roper.
Between 2018 and now, intel/display has changed so much that another
rewrite was necessary.
v2:
- Set initial background color (black) via proper helper function (Bob)
- Fix debugfs output
- General rebasing
v3 (Maarten):
- Rebase on top of recent changes.
v4 (Maarten):
- Complete rewrite based on the solution that went upstream, and
on the new intel color management features.
Cc: Chandra Konduru <chandra.konduru@intel.com>
Cc: dri-devel@lists.freedesktop.org
Co-developed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Link: https://patch.msgid.link/20260505200133.636584-2-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
We short-cut skl_scaler_get_config() when skl_pipe_scaler_get_hw_state()
has failed. Remove codepaths that assume scaler_id < 0.
Cc: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260509164048.627399-10-michal.grzelak@intel.com
Add a helper function hiding the search for scaler_id.
Changelog:
v2->v3
- keep ctl inside the loop (Ville)
- separate impure function call from variable declaration block (Ville)
Cc: Nemesa Garg <nemesa.garg@intel.com>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260509164048.627399-9-michal.grzelak@intel.com
Most of the loop's code is run once because of the continue statement at
it's start and break statement at it's end. Kick it out of the loop.
While at it, skl_scaler_get_config()'s loop is skipped when specified
condition is met and broken when the condition is not met. Equivalently,
invert the condition and break the loop.
Changelog:
v2->v3
- keep ctl inside the loop (Ville)
Cc: Nemesa Garg <nemesa.garg@intel.com>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260509164048.627399-8-michal.grzelak@intel.com
id is not really used anywhere in skl_scaler_get_config(). Replace it
with scaler_id.
Return if no scaler was found.
v1->v2
- check if any scaler was found (Ville)
Cc: Nemesa Garg <nemesa.garg@intel.com>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260509164048.627399-7-michal.grzelak@intel.com
Switch from generic iterator naming into more specific scaler_id where
it is possible.
Cc: Nemesa Garg <nemesa.garg@intel.com>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260509164048.627399-6-michal.grzelak@intel.com
Stick to using snake_case in intel_casf_scaler_compute_coeff() where
it is possible.
Cc: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260509164048.627399-5-michal.grzelak@intel.com
Add more description to the casf_coeff()'s argument and
casf_coeff_tap()'s returned value.
Do the same for glk_nearest_filter_coef().
v1->v2
- apply the rename to nearest neighbor filter (Ville)
Cc: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260509164048.627399-4-michal.grzelak@intel.com
Stick to the notion of already used *_coeff*() instead of *_coef*().
Rename that way convert_sharpness_coef_binary() and
intel_casf_scaler_compute_coef().
v1->v2
- rename intel_casf_scaler_compute_coef()
Cc: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260509164048.627399-3-michal.grzelak@intel.com
Remove superfluous whitespace character and fix the spelling.
Cc: Nemesa Garg <nemesa.garg@intel.com>
Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260509164048.627399-2-michal.grzelak@intel.com
This reverts commit 40d2f58209.
Removing the try_vesa_interface gate caused a backlight regression on
panels whose VBT correctly reports INTEL_BACKLIGHT_DISPLAY_DDI and whose
PWM path is the actual backlight control, but whose DPCD optimistically
advertises DP_EDP_BACKLIGHT_AUX_ENABLE_CAP / _BRIGHTNESS_AUX_SET_CAP.
After the commit such panels silently bind to the VESA AUX backlight
funcs; AUX writes complete but the panel ignores them, leaving
brightness stuck (no-op backlight). Observed on at least KBL and TGL
eDP setups.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260517024709.1016121-1-suraj.kandpal@intel.com
The macro HAS_DMC_WAKELOCK() is currently only used inside
intel_dmc_wl.c and doesn't need to be exposed to the rest of the driver.
Furthermore, there is a distinction between the display IP having
support for the feature and the driver actually using it, so using
HAS_DMC_WAKELOCK() outside of intel_dmc_wl.c would potentially be wrong
anyway.
Let's drop that macro. If other part of the driver needs to check if
the driver is using the DMC wakelock feature, we would need actually to
expose the function __intel_dmc_wl_supported().
Since HAS_DMC_WAKELOCK() was kind of self-documenting in the sense that
it tells us what display IPs have support for the feature and we are now
dropping it, let's also take this opportunity to add a documentation
note on the subject.
Reviewed-by: Daniel Charles <daniel.charles@intel.com>
Link: https://patch.msgid.link/20260429-drop-has_dmc_wakelock-v1-1-62cb6fab1da0@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Just like it is done for the platform-specific bandwidth parameters, use
a separate function named get_display_bw_params() to return the display
IP-specific parameters. This simplifies intel_bw_init_hw() by having
just one call for each of the *_get_bw_info() functions.
v2:
- Prefer to call get_display_bw_params() only once in
intel_bw_init_hw() instead of having multiple calls in each of the
affected *_get_bw_info() functions. (Jani)
v3:
- Call get_display_bw_params() only after the check on
HAS_DISPLAY(display). (Jani)
- Return &gen11_bw_params only if display version is 11. (Matt)
v4:
- Like done with get_soc_bw_params(), drop drm_WARN() when no display
IP is matched.
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260518-separate-platform-from-diplay-ip-specific-bw-params-v4-5-918528006549@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
To align with struct intel_platform_bw_params, rename struct
intel_sa_info to intel_display_bw_params. Also add comments to contrast
their purposes.
v2:
- Use gen11 and gen12 as prefixes for ICL's and TGL's display-specific
parameters variables. (Matt)
- Prefer to use "display" instead of "disp" in variable names. (Jani)
- Drop the redundant "disp" from the variable names.
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260518-separate-platform-from-diplay-ip-specific-bw-params-v4-4-918528006549@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Now that intel_sa_info contains bandwidth parameters specific to the
display IP, we can drop many duplicates and reuse from previous
releases.
Let's do that and also simplify intel_bw_init_hw() while at it.
v2:
- Drop rkl_sa_info and reuse icl_sa_info. (Matt)
- Add comment explaining RKL's display's peculiarity on using ICL's
parameters. (Matt)
- Don't rename xelpdp_sa_info to mtl_sa_info. Renaming of instances
to use IP names will be done in upcoming changes.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260518-separate-platform-from-diplay-ip-specific-bw-params-v4-3-918528006549@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
We got confirmation from the hardware team that the bandwidth parameters
deprogbwlimit and derating are platform-specific and not tied to the
display IP. As such, let's make sure that we use platform checks for
those.
The rest of the members of struct intel_sa_info are tied to the display
IP and we will deal with them as a follow-up.
v2:
- Use good old if-ladder instead of weird-looking pattern "assign ret,
check platform, then return ret". (Jani, Matt)
- Have a single call site for get_platform_bw_params() and pass the
result as parameter to the *_get_bw_info() functions. (Jani)
- Avoid using "plat" as abbreviation for "platform". (Jani)
- s/_plat_bw_params/_bw_params/, since all of the instances are
prefixed with platform names. (Jani)
- s/struct intel_platform_bw_params/struct intel_soc_bw_params/.
(Matt)
- Do not return a default value; prefer to return NULL and
intentionally cause a NULL pointer dereference if a platform is
missing. (Gustavo)
v3:
- Call get_soc_bw_params() only after the check on
HAS_DISPLAY(display). (Jani)
- Combine if-ladder branches for adl_s_bw_params into a single one.
(Matt)
- Flatten if-ladder by checking for WCL before PTL (as opposed to
checking for WCL inside the brace for PTL). (Matt)
- Bail out of intel_bw_init_hw() if display version is below 11.
(Gustavo)
v4:
- Drop drm_WARN() when no platform was matched to avoid
special-casing DG2 and any other platform that doesn't use
SoC-specific parameters. (Jani)
- Pass dram_info to get_soc_bw_params() to keep a single call to
intel_dram_info(). (Jani)
- Don't use 2 separate if-ladders (one for client and another for
discrete platforms) and keep a single one for simplicity. (Gustavo)
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260518-separate-platform-from-diplay-ip-specific-bw-params-v4-2-918528006549@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
PTL with physically disconnected display was observed to have 40s longer
execution time when testing xe_fault_injection@xe_guc_mmio_send_recv.
The issue has not been seen when reverting commit 40a9f77a28 ("Revert
"drm/i915/dp: change aux_ctl reg read to polling read"").
Apparently the configuration suffers from not having AUX enabled when
using interrupts. One probable cause can be xe enabling interrupts too
late: interrupts need memory allocations which currently can't be done
before the display FB takeover is done.
As for now, use polling for AUX in case interrupts are unavailable.
Fixes: 40a9f77a28 ("Revert "drm/i915/dp: change aux_ctl reg read to polling read"")
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260416163744.288107-1-michal.grzelak@intel.com
In Xe3p there is an HW optimization done. When there is an SU triggered in
Capture state, Link will be kept ON post Capture CRC SDP. Before valid SU
pixels Intel source will transmit dummy pixels. Some TCONS are improperly
considering these dummy pixels as a valid pixel data. Prior Xe3p link was
was turned off even if there was SU triggered in capture state and no dummy
pixels were transmitted. These dummy pixels are problem only if SDP on
prior scanline is used and Early Transport is not in use. The workaround is
to start SU area always at scanline 0.
v2: use intel_display_wa
Bspec: 74741, 79482
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260515095756.2799483-5-jouni.hogander@intel.com
There is Intel specific workaround DPCD address containing workaround for
case where SDP is on prior line. Apply this workaround according to values
in the offset.
Fixes: 61e887329e ("drm/i915/xelpd: Handle PSR2 SDP indication in the prior scanline")
Cc: <stable@vger.kernel.org> # v5.15+
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260515095756.2799483-4-jouni.hogander@intel.com
Read Intel DPCD workaround register and store it into
intel_connector->dp.psr_caps. psr_caps was chosen as currently it contains
only PSR workaround for PSR2 SDP on prior scanline implementation.
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260515095756.2799483-3-jouni.hogander@intel.com
EDP specification says:
"If either VSC SDP is unable to be transmitted 100 ns before the SU region,
the Source device may optionally transmit the VSC SDP during the prior
video scan line’s HBlank period There is a Intel specific drm dp register
currently containing bits related how TCON can support PSR2 with SDP on
prior line."
Unfortunately many panels are having problems in implementing this. So
there is a custom Intel specific DPCD register (INTEL_WA_REGISTER_CAPS) to
figure out if this is properly implemented on a panel or if panel doesn't
require that 100 ns delay before the SU region. Here are the definitions in
this custom DPCD address:
0 = Panel doesn't support SDP on prior line
1 = Panel supports SDP on prior line
2 = Panel doesn't have 100ns requirement
3 = Reserved
Add definitions for this new register and it's values into new header
intel_dpcd.h.
v2: add INTEL_DPCD_ prefix to definitions
Bspec: 74741
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260515095756.2799483-2-jouni.hogander@intel.com
Add sdp_type in AS SDP unpack. Since the field sdp_type is not compared
in intel_compare_dp_as_sdp() it doesn't throw up any mismatch error yet.
In the subsequent change this field will be added along with other missing
fields for comparison.
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/20260511123218.1589830-4-ankit.k.nautiyal@intel.com
Correct the bit-shift logic to properly readback the 10 bit target_rr from
DB3 and DB4.
v2: Align the style with readback for vtotal. (Ville)
Fixes: 12ea892916 ("drm/i915/dp: Add Read/Write support for Adaptive Sync SDP")
Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
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/20260511123218.1589830-2-ankit.k.nautiyal@intel.com
Call the platform specific display irq ack hooks, if any, via
intel_display_irq_ack().
Check for HAS_DISPLAY() in intel_display_irq_ack() for completeness even
though fusing is not possible on the platforms in question.
v3:
- Pure vfunc change (Ville)
v2:
- Include LPE audio in the ack part
- Check for HAS_DISPLAY()
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/a72974d66f7696ca35380b44f13f938b2d4d690d.1778688699.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Add a number of *_display_irq_handler() functions to group together the
various display irq handler parts for the platforms, to declutter the
core i915 irq code from the details.
Add master_ctl to struct intel_display_irq_state, and pass the state
pointer to the handlers where necessary. The handler function signatures
are intentionally the same to allow for more refactoring.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/5088a9a658ce9a57049c999ee2ebababd7536b6c.1778688699.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Add i9xx_display_irq_ack() and vlv_display_irq_ack() to group together
the various irq ack parts for the platforms, to declutter the core i915
irq code from the details.
Introduce struct intel_display_irq_state to group together all the data
the ack functions need. In the follow-up, this state will be passed on
to similar platform specific handler functions.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/30d2f1c0c6acd997b841f0dfc538f703e064998d.1778688699.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Call the platform specific display irq postinstall hooks via
intel_display_irq_postinstall().
Relocate the gen11 HAS_DISPLAY() check to
intel_display_irq_postinstall(), as the funcs pointer won't be
initialized for no display.
v2:
- relocate HAS_DISPLAY() (Sashiko)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/65f1ad73628fb6dbdf6e782493eaecb1d61abaf7.1778688699.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Introduce display irq hooks with struct intel_display_irq_funcs, and add
the ->reset hook as the first thing. Call the reset hooks from i915 and
xe core via intel_display_irq_reset().
Relocate the gen8 and gen11 HAS_DISPLAY() check to
intel_display_irq_reset(), as the funcs pointer won't be initialized for
no display.
Note: We're increasingly moving to the territory of not touching display
at all if there's no display or it has been fused off. Which is good,
but care must be taken to not have hardware setup required also for no
display cases in display code. Also note that the line is fuzzy for
older platforms, but there we also don't have fusing.
v2:
- make the structs static const (Sashiko)
- relocate HAS_DISPLAY() (Sashiko)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/f9d75e8af92b5550a9d07f29491be5313b7c866b.1778688699.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The xe driver keeps track of whether to probe display, and whether
display hardware is there, using xe->info.probe_display. It gets set to
false if there's no display after intel_display_device_probe(). However,
the display may also be disabled via fuses, detected at a later time in
intel_display_device_info_runtime_init().
In this case, the xe driver does for_each_intel_crtc() on uninitialized
mode config in xe_display_flush_cleanup_work(), leading to a NULL
pointer dereference, and generally calls display code with display info
cleared.
Check for intel_display_device_present() after
intel_display_device_info_runtime_init(), and reset
xe->info.probe_display as necessary. Also do unset_display_features()
for completeness, although display runtime init has already done
that. This will need to be unified across all cases later.
Move intel_display_device_info_runtime_init() call slightly earlier,
similar to i915, to avoid a bunch of unnecessary setup for no display
cases.
Note #1: The xe driver has no business doing low level display plumbing
like for_each_intel_crtc() to begin with. It all needs to happen in
display code.
Note #2: The actual bug is present already in commit 44e694958b
("drm/xe/display: Implement display support"), but the oops was likely
introduced later at commit ddf6492e0e ("drm/xe/display: Make display
suspend/resume work on discrete").
Fixes: 44e694958b ("drm/xe/display: Implement display support")
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7904
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/6150
Cc: stable@vger.kernel.org # v6.8+
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260515160920.1082842-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
