summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-02-15drm/i915: Simplify vlv_wait_port_ready() argumentsVille Syrjälä
Currently vlv_wait_port_ready() takes the display+dig_port, but all it really needs is the encoder. The display can be dug out from therein. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213150220.13580-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-02-15drm/i915: Relocate vlv_wait_port_ready()Ville Syrjälä
While vlv_wait_port_ready() doens't directly talk to the VLV/CHV DPIO PHY, the signals it's looking for do come from the PHY. So it seems appropriate to relocate it into intel_dpio_phy.c. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213150220.13580-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-02-15drm/i915: Move intel_plane_destroy() into intel_atomic_plane.cVille Syrjälä
intel_atomic_plane.c (should rename it really) has become our standard place for generic plane code. Move intel_plane_destroy() there so it doesn't clutter intel_display.c. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213150220.13580-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-02-15drm/i915: Move intel_hpd_poll_fini() into intel_hotplug.cVille Syrjälä
The name of intel_hpd_poll_fini() suggests that it should live in intel_hotplug.c. Make it so. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213150220.13580-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-02-15drm/i915: Extract intel_hdcp_cancel_works()Ville Syrjälä
Hide the annoying HDCP implementation details better by providing a intel_hdcp_cancel_works(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213150220.13580-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-02-15drm/i915: Extract intel_connector_cancel_modeset_retry_work()Ville Syrjälä
Hide the implementation details of the modeset retry work better. v2: Include prototype and sort includes correctly (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213150220.13580-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-02-15drm/i915: Always initialize connector->modeset_retry_workVille Syrjälä
Since we have all the necessary bits in intel_connector.c might as well always initialize the modeset_retry_work for every connector. Avoids yet another init function you have to remember to call. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213150220.13580-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-02-15drm/i915: Move modeset_retry stuff into intel_connector.cVille Syrjälä
Most of the modeset retry stuff looks to be entirely generic, and so there doesn't seem to any reason to keep it in intel_dp.c. Move the generic bits into intel_connector.c. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213150220.13580-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-02-15drm/i915: Relocate intel_atomic_check_planes()Ville Syrjälä
Move all the intel_atomic_check_planes() machinery into intel_atomic_plane.c in order to declutter intel_display.c. v2: Rebase due to intel_display changes Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250212164330.16891-11-ville.syrjala@linux.intel.com
2025-02-15drm/i915: Move icl+ nv12 plane register mangling into skl_universal_plane.cVille Syrjälä
Try to keep all the low level skl+ universal plane register details inside skl_universal_plane.c instead of having them sprinkled all over the place. v2: Rebase due to intel_display changes Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250212164330.16891-10-ville.syrjala@linux.intel.com
2025-02-15drm/i915: Rename the variables in icl_check_nv12_planes()Ville Syrjälä
All the this generic 'plane' vs 'linked' stuff is hard to follow. Rename the variables to use the y_plane vs. uv_plane terminology to make it clear which is which. v2: Rebase due to intel_display changes Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250212164330.16891-9-ville.syrjala@linux.intel.com
2025-02-15drm/i915: Extract link_nv12_planes()Ville Syrjälä
Pull the code linking the UV and Y planes together into a sensible function instead of having the code plastered inside the higher level loop. v2: Rebase due to intel_display changes Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250212164330.16891-8-ville.syrjala@linux.intel.com
2025-02-15drm/i915: Remove pointless visible check in unlink_nv12_plane()Ville Syrjälä
visible can't be true when is_y_plane is true. Replace the bogus check with an WARN_ON(). Flatten the function while at it. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250212164330.16891-7-ville.syrjala@linux.intel.com
2025-02-15drm/i915: Extract unlink_nv12_plane()Ville Syrjälä
Pull the details of the nv12 plane unlinking to a small function to make the higher level code less messy. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250212164330.16891-6-ville.syrjala@linux.intel.com
2025-02-15drm/i915: s/planar_slave/is_y_plane/Ville Syrjälä
Bspec talks about Y planes, not planar slaves. Switch to using the same terminology to make life a bit less confusing. v2: Adjust some comments too (Maarten) Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250212164330.16891-5-ville.syrjala@linux.intel.com
2025-02-15drm/i915: Rework joiner and Y plane dependency handlingVille Syrjälä
The current code tries to handle joiner vs. Y planes completely independently. That does not really work since each pipe selects its Y planes completely independently, and any plane pulled into the state by one of the secondary pipes needs to have the plane on the primary pipe also included in the state (for the uapi state copy). The current code sometimes forgets to pull in planes that we need, leading to weird things like the Y<->UV plane link only getting torn down from one side but not the other. Remedy the situation by pulling in the exact same set planes on all the joined pipes. To calculate the set we simply look through each joined crtc and any plane in the state gets added to the set. However due to the way the Y plane selection works we may not be able to determine the set in one go. One plane on one pipe may pull in a Y plane, which may have to pull in another plane because it's not acting in the same role on another pipe, etc. The simple approach taken here is to keep looping and adding planes to the set until it stops growing. I suppose if we tracked more of this Y plane stuff in the crtc state rather than the plane state we might be able to do it in one go. But this works, and it's not going to loop for long anyway since we only have so many pipes and Y planes to consider. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250212164330.16891-4-ville.syrjala@linux.intel.com
2025-02-15Revert "drm/i915: Fix NULL ptr deref by checking new_crtc_state"Ville Syrjälä
This reverts commit 1d5b09f8daf859247a1ea65b0d732a24d88980d8. Now that the root cause the missing crtc state has been fixed we can get rid of the duct tape. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250212164330.16891-3-ville.syrjala@linux.intel.com
2025-02-15drm/i915: Make sure all planes in use by the joiner have their crtc includedVille Syrjälä
Any active plane needs to have its crtc included in the atomic state. For planes enabled via uapi that is all handler in the core. But when we use a plane for joiner the uapi code things the plane is disabled and therefore doesn't have a crtc. So we need to pull those in by hand. We do it first thing in intel_joiner_add_affected_crtcs() so that any newly added crtc will subsequently pull in all of its joined crtcs as well. The symptoms from failing to do this are: - duct tape in the form of commit 1d5b09f8daf8 ("drm/i915: Fix NULL ptr deref by checking new_crtc_state") - the plane's hw state will get overwritten by the disabled uapi state if it can't find the uapi counterpart plane in the atomic state from where it should copy the correct state Cc: stable@vger.kernel.org Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250212164330.16891-2-ville.syrjala@linux.intel.com
2025-02-14drm/i915/ddi: Sanitize DDI_BUF_CTL register definitionsImre Deak
Align the DDI_BUF_CTL register flag definitions with how this is done elsewhere. v2: Robustify macro calls with parens. (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-12-imre.deak@intel.com
2025-02-14drm/i915/ddi: Add a helper to enable a portImre Deak
Add a helper to enable a port instead of open-coding it. While at it rename intel_disable_ddi_buf() to intel_ddi_buf_disable() for consistency. v2: (Jani) - s/intel_enable_ddi_buf/intel_ddi_buf_enable - s/intel_disable_ddi_buf/intel_ddi_buf_disable Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-11-imre.deak@intel.com
2025-02-14drm/i915/ddi: Unify the platform specific functions disabling a portImre Deak
The functions disabling a port for MTL+ and earlier platforms only differ by an extra step on MTL+ (to disable the D2D link) and the point at which the port's idle state is waited for. Combine the two functions accounting for the above differences, removing the duplication. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-10-imre.deak@intel.com
2025-02-14drm/i915/ddi: Move platform checks within mtl_ddi_enable/disable_d2d_link()Imre Deak
The prefix of the mtl_ddi_enable_d2d() / mtl_ddi_disable_d2d_link() names show already what are the relevant platforms, so the corresponding platform check is a detail that can be hidden in the functions, do so. While at it rename mtl_ddi_disable_d2d_link() to mtl_ddi_disable_d2d() for symmetry with mtl_ddi_enable_d2d(). v2: s/mtl_ddi_disable_d2d_link/mtl_ddi_disable_d2d (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-9-imre.deak@intel.com
2025-02-14drm/i915/ddi: Simplify waiting for a port to get active/idle via DDI_BUF_CTLImre Deak
When waiting for a port to get active/idle there is no point in the complexity of specifying an exact timeout and for that the suitable wait API instead of just using the maximum timeout. The sequence in particular is not performance critical at all either and due to scheduling it's not guaranteed anyhow how long the wait will last at the given timescale. In the usual case where the wait succeeds the actual time waited does not change with the increased timeout. Simplify things accordingly, describing the bspec platform specific timeouts in code comments. v2: Clarify the rationale in the commit log. (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://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-8-imre.deak@intel.com
2025-02-14drm/i915/ddi: Simplify the port disabling via DDI_BUF_CTLImre Deak
A port can be disabled only via a modeset (or during HW state sanitization) when the port is enabled. Thus it's not required to check the port's enabled state before disabling it. In any case if the port happened to be disabled, the following disabling would be just a nop and waiting for the buffer's idle state should succeed. Simplify the disabling sequence accordingly. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-7-imre.deak@intel.com
2025-02-14drm/i915/ddi: Simplify the port enabling via DDI_BUF_CTLImre Deak
In the past intel_digital_port::dp.prepare_link_retrain() could be called directly (vs. from a modeset) to retrain an enabled link. In that case the port had to be first disabled and then re-enabled. That changed with commit 2885d283cce5 ("drm/i915/dp: Retrain SST links via a modeset commit"), after which the only way prepare_link_retrain() can be called is from a modeset during link training when the port is still disabled. Simplify things accordingly, assuming the disabled port state. v2: Don't use drm_i915_private in intel_ddi_prepare_link_retrain(). (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-6-imre.deak@intel.com
2025-02-14drm/i915/ddi: Set missing TC DP PHY lane stagger delay in DDI_BUF_CTLImre Deak
Add the missing PHY lane stagger delay programming for ICL-ADL platforms on TypeC DP outputs. v2: (Jani) - Clarify code comment about lane stagger programming. - Robustify macro calls with parens. Bspec: 7534, 49533 Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-5-imre.deak@intel.com
2025-02-14drm/i915/ddi: Make all the PORT_WIDTH macros work the same wayImre Deak
Make the PORT_WIDTH macro of the XELPDP_PORT_CTL1 register work the same way as those used for the DDI_BUF_CTL and the TRANS_DDI_FUNC_CTL registers: accept a width parameter and convert it to the given register's encoding. v2: Robustify macro calls with parens. (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-4-imre.deak@intel.com
2025-02-14drm/i915/ddi: Fix HDMI port width programming in DDI_BUF_CTLImre Deak
Fix the port width programming in the DDI_BUF_CTL register on MTLP+, where this had an off-by-one error. Cc: <stable@vger.kernel.org> # v6.5+ Fixes: b66a8abaa48a ("drm/i915/display/mtl: Fill port width in DDI_BUF_/TRANS_DDI_FUNC_/PORT_BUF_CTL for HDMI") Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-3-imre.deak@intel.com
2025-02-14drm/i915/dsi: Use TRANS_DDI_FUNC_CTL's own port width macroImre Deak
The format of the port width field in the DDI_BUF_CTL and the TRANS_DDI_FUNC_CTL registers are different starting with MTL, where the x3 lane mode for HDMI FRL has a different encoding in the two registers. To account for this use the TRANS_DDI_FUNC_CTL's own port width macro. Cc: <stable@vger.kernel.org> # v6.5+ Fixes: b66a8abaa48a ("drm/i915/display/mtl: Fill port width in DDI_BUF_/TRANS_DDI_FUNC_/PORT_BUF_CTL for HDMI") Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-2-imre.deak@intel.com
2025-02-14drm/i915/psr: Allow DSB usage when PSR is enabledJouni Högander
Now as we have correct PSR2_MAN_TRK_CTL handling in place we can allow DSB usage also when PSR is enabled for LunarLake onwards. v2: rebase Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-14-jouni.hogander@intel.com
2025-02-14drm/i915/display: Ensure we have "Frame Change" event in DSB commitJouni Högander
We may have commit which doesn't have any non-arming plane register writes. In that case there aren't "Frame Change" event before DSB vblank evasion which hangs as PIPEDSL register is reading as 0 when PSR state is SRDENT(PSR1) or DEEP_SLEEP(PSR2). Handle this by ensuring "Frame Change" event at the begin of DSB commit if using PSR/PR. v3: dsb_commit as a first parameter v2: use intel_psr_trigger_frame_change_event Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-13-jouni.hogander@intel.com
2025-02-14drm/i915/psr: Add function for triggering "Frame Change" eventJouni Högander
Add new function to trigger "Frame Change" event for ensuring we are waking up before vblank evasion. v2: dsb as a first parameter Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-12-jouni.hogander@intel.com
2025-02-14drm/i915/display: Evade scanline 0 as well if PSR1 or PSR2 is enabledJouni Högander
PIPEDSL is reading as 0 when in SRDENT(PSR1) or DEEP_SLEEP(PSR2). On wake-up scanline counting starts from vblank_start - 1. We don't know if wake-up is already ongoing when evasion starts. In worst case PIPEDSL could start reading valid value right after checking the scanline. In this scenario we wouldn't have enough time to write all registers. To tackle this evade scanline 0 as well. As a drawback we have 1 frame delay in flip when waking up. v2: - use intel_dsb_emit_wait_dsl - add evasion of scanline 0 also for Panel Replay Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-11-jouni.hogander@intel.com
2025-02-14drm/i915/psr: Remove DSB_SKIP_WAITS_EN chicken bitJouni Högander
We have different approach on how flip is considered being complete. We are waiting for vblank on DSB and generate interrupt when it happens and this interrupt is considered as indication of completion -> we definitely do not want to skip vblank wait. Also not skipping scanline wait shouldn't cause any problems if we are in DEEP_SLEEP PIPEDSL register is returning 0 -> evasion does nothing and if we are not in DEEP_SLEEP evasion works same way as without PSR. v2: add comment explaining why we are not setting DSB_SKIP_WAITS_EN Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-10-jouni.hogander@intel.com
2025-02-14drm/i915/display: Warn on use_dsb in non-dsb pipe update functionsJouni Högander
Add drm_WARN_ON(use_dsb) into commit_pipe_{pre,post}_planes() and intel_pipe_update_{start,end}() as they are not supposed to get called on non-dsb updates. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-9-jouni.hogander@intel.com
2025-02-13drm/i915/psr: Write PSR2_MAN_TRK_CTL on DSB commit as wellJouni Högander
Add PSR2_MAN_TRK_CTL writing into DSB commit in intel_atomic_dsb_finish. Taking PSR lock over DSB commit is not needed because PSR2_MAN_TRK_CTL is now written only by DSB. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-8-jouni.hogander@intel.com
2025-02-13drm/i915/psr: Allow writing PSR2_MAN_TRK_CTL using DSBJouni Högander
Allow writing PSR2_MAN_TRK_CTL using DSB by using intel_de_write_dsb. Do not check intel_dp->psr.lock being held when using DSB. This assertion doesn't make sense as in case of using DSB the actual write happens later and we are not taking intel_dp->psr.lock mutex over dsb commit. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-7-jouni.hogander@intel.com
2025-02-13drm/i915/psr: Use SFF_CTL on invalidate/flush for LunarLake onwardsJouni Högander
In LunarLake we have SFF_CTL register which contains SFF bit ored with respective SFF bit in PSR2_MAN_TRK_CTL register. Use this register instead of the bit in PSR2_MAN_TRK_CTL on frontbuffer tracking callbacks. This helps us avoiding taking psr mutex when performing atomic commit. We don't need to set the CFF bit as selective update configuration in PSR2_MAN_TRL_CTL is not overwritten anymore. I.e. we have valid configuration in PSR2_MAN_TRK_CTL and in plane SEL_FETCH_* registers when SFF bit gets cleared by the HW in case something triggers "frame change" event after SFF bit is cleared. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-6-jouni.hogander@intel.com
2025-02-13drm/i915/psr: Add register definitions for SFF_CTL and CFF_CTL registersJouni Högander
Add register definitions for SFF_CTL and CFF_CTL registers. Name them as LNL_SFF_CTL and LNL_CFF_CTL. v2: use _MMIO_TRANS instead of _MMIO_TRANS2 Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-5-jouni.hogander@intel.com
2025-02-13drm/i915/psr: Split setting sff and cff bits away from intel_psr_force_updateJouni Högander
This is a clean-up and a preparation for adding own SFF and CFF registers for LunarLake onwards. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-4-jouni.hogander@intel.com
2025-02-13drm/i915/psr: Rename psr_force_hw_tracking_exit as intel_psr_force_updateJouni Högander
psr_force_hw_tracking_exit is misleading name as it is used for PSR1, PSR2 HW tracking and PSR2 selective fetch. Due to this rename it as intel_psr_force_update. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-3-jouni.hogander@intel.com
2025-02-13drm/i915/psr: Use PSR2_MAN_TRK_CTL CFF bit only to send full updateJouni Högander
We are preparing for a change where only frontbuffer flush will use single full frame bit of a new register (SFF_CTL) available on LunarLake onwards. It shouldn't be necessary to have SFF bit set if CFF bit is set in PSR2_MAN_TRK_CTL -> removing setting it on all platforms as there is not reason to have it different on older platforms. v2: commit message improved Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213064804.2077127-2-jouni.hogander@intel.com
2025-02-13drm/i915/display: convert i915_pipestat_enable_mask() to struct intel_displayJani Nikula
Going forward, struct intel_display is the main display device data pointer. Convert i915_pipestat_enable_mask() to struct intel_display, allowing further conversions elsewhere. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/975b382c703cfb62f24643e40eac247b8e8bbea8.1739378096.git.jani.nikula@intel.com
2025-02-13drm/i915/display: convert intel_fifo_underrun.[ch] to struct intel_displayJani Nikula
Going forward, struct intel_display is the main display device data pointer. Convert as much as possible of intel_fifo_underrun.[ch] to struct intel_display. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/682e667013e1726a6f2f78484b7e9618cee3b639.1739378096.git.jani.nikula@intel.com
2025-02-13drm/i915/combo-phy: convert intel_combo_phy.[ch] to struct intel_displayJani Nikula
Going forward, struct intel_display is the main display device data pointer. Convert as much as possible of intel_combo_phy.[ch] to struct intel_display, along with intel_phy_is_combo() in intel_display.c. Drive-by convert some drm_dbg() to drm_dbg_kms() while at it. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c2e0a6294a8eaa4c16632881edc4f2d23c576101.1739378096.git.jani.nikula@intel.com
2025-02-13drm/i915/dsi: convert platform checks to display->platform.<platform> styleJani Nikula
These are stragglers from a time the display->platform mechanism didn't exist. Finish the conversion. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/493e4c550f9c515e2e82df1afd8a74a24156e76e.1739378096.git.jani.nikula@intel.com
2025-02-13drm/i915/display: convert intel_mode_valid_max_plane_size() to intel_displayJani Nikula
Going forward, struct intel_display is the main display device data pointer. Convert the intel_mode_valid_max_plane_size() helper to struct intel_display, allowing further conversions elsewhere. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6e7810c793ecc8ff6a31569830bf162156245668.1739378095.git.jani.nikula@intel.com
2025-02-13drm/i915/display: convert intel_cpu_transcoder_mode_valid() to intel_displayJani Nikula
Going forward, struct intel_display is the main display device data pointer. Convert the intel_cpu_transcoder_mode_valid()() helper to struct intel_display, allowing further conversions elsewhere. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f9246a00a2e7aabaffb86f863915a4307e1fd3f8.1739378095.git.jani.nikula@intel.com
2025-02-13drm/i915/sdvo: convert intel_sdvo.[ch] to struct intel_displayJani Nikula
Going forward, struct intel_display is the main display device data pointer. Convert as much as possible of intel_sdvo.[ch] to struct intel_display. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/2e79909f8a060d7ff1744911f8da9300eb1f225c.1739378095.git.jani.nikula@intel.com
2025-02-13drm/i915/display: convert intel_set_{cpu,pch}_fifo_underrun_reporting() to ↵Jani Nikula
intel_display Going forward, struct intel_display is the main display device data pointer. Convert intel_set_cpu_fifo_underrun_reporting() and intel_set_pch_fifo_underrun_reporting() to struct intel_display, along with some of the call chains from there. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3b984d0183214d05d0cdecad35184ea8d89ae050.1739378095.git.jani.nikula@intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-29 02:41:18 +0000