summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-02-27drm/i915/snps: convert intel_snps_phy.[ch] to struct intel_displayJani Nikula
Going forward, struct intel_display is the main display device data pointer. Convert the intel_snps_phy.[ch] to struct intel_display. Also convert the very much related intel_phy_is_snps() helper. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/2dcc9313f5cf7777af3b6f20124526f6b9462b91.1740502116.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-02-27drm/i915/tdf: convert intel_tdf.[ch] to struct intel_displayJani Nikula
Going forward, struct intel_display is the main display device data pointer. Convert the intel_tdf.[ch] glue to struct intel_display. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/26d976f23295713f9a7cda20e32b7ef5aad3dd9e.1740502116.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-02-27drm/i915/debugfs: continue display debugfs struct intel_display conversionJani Nikula
Nudge intel_display_debugfs.[ch] conversion to struct intel_display forward. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e1262dc019d42ed0e294606fc875427bda336cb9.1740502116.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-02-27drm/i915/display: remove leftover struct drm_i915_private forward declarationsJani Nikula
A number of unused struct drm_i915_private forward declarations have been left behind. Remove them. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ef354c3d812ac33061628063548b932507fdc9b7.1740502116.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-02-27drm/i915/mst: update max stream count to match number of pipesJani Nikula
We create the stream encoders and attach connectors for each pipe we have. As the number of pipes has increased, we've failed to update the topology manager maximum number of payloads to match that. Bump up the max stream count to match number of pipes, enabling the fourth stream on platforms that support four pipes. Cc: stable@vger.kernel.org Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250226135626.1956012-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-02-26drm/i915: Fix pipeDMC and ATS fault handlingVille Syrjälä
The fault handler is supposed to return true when it handles the fault. The pipeDMC and ATS handlers are returning false instead which results in the "unreported faults" WARN triggering when it shouldn't. Fixes: f13011a79999 ("drm/i915: Pimp display fault reporting") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250224173017.29500-1-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
2025-02-26drm/i915/power: move runtime power status info to power debugfsJani Nikula
The i915 core debugfs has no business looking at power domain guts for runtime power status. Move the info to the more appropriate place. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250225121742.721871-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-02-25drm/i915/dp_mst: Fix encoder HW state readout for UHBR MSTImre Deak
The encoder HW/SW state verification should use a SW state which stays unchanged while the encoder/output is active. The intel_dp::is_mst flag used during state computation to choose between the DP SST/MST modes can change while the output is active, if the sink gets disconnected or the MST topology is removed for another reason. A subsequent state verification using intel_dp::is_mst leads then to a mismatch if the output is disabled/re-enabled without recomputing its state. Use the encoder's active MST link count instead, which will be always non-zero for an active MST output and will be zero for SST. Fixes: 35d2e4b75649 ("drm/i915/ddi: start distinguishing 128b/132b SST and MST at state readout") Fixes: 40d489fac0e8 ("drm/i915/ddi: handle 128b/132b SST in intel_ddi_read_func_ctl()") Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250224093242.1859583-1-imre.deak@intel.com
2025-02-20drm/i915/hdcp: Create force_hdcp14 debug fs entrySuraj Kandpal
Testing HDCP 1.4 becomes tough since the only way our code comes to HDCP 1.4 pathway is if the monitor only supports HDCP 1.4 which becomes tough to find sometimes. Setting this debug_fs entry will force use to use the HDCP 1.4 path so that more robust HDCP 1.4 testing can take place. --v2 -Move the code to intel_hdcp.c [Jani] -Remove useless debug logging [Jani] -Remove Force_HDCP from the debug file [Jani] --v3 -Remove leftover debug loggings [Jani] Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213082541.3772212-1-suraj.kandpal@intel.com
2025-02-19drm/i915/dp: Fix disabling the transcoder function in 128b/132b modeImre Deak
During disabling the transcoder in DP 128b/132b mode (both in case of an MST master transcoder and in case of SST) the transcoder function must be first disabled without changing any other field in the register (in particular leaving the DDI port and mode select fields unchanged) and clearing the DDI port and mode select fields separately, later during the disabling sequences. Fix the sequence accordingly. Bspec: 54128, 65448, 68849 Cc: Jani Nikula <jani.nikula@intel.com> Fixes: 79a6734cd56e ("drm/i915/ddi: disable trancoder port select for 128b/132b SST") Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250217223828.1166093-3-imre.deak@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-02-19drm/i915/dp: Fix error handling during 128b/132b link trainingImre Deak
At the end of a 128b/132b link training sequence, the HW expects the transcoder training pattern to be set to TPS2 and from that to normal mode (disabling the training pattern). Transitioning from TPS1 directly to normal mode leaves the transcoder in a stuck state, resulting in page-flip timeouts later in the modeset sequence. Atm, in case of a failure during link training, the transcoder may be still set to output the TPS1 pattern. Later the transcoder is then set from TPS1 directly to normal mode in intel_dp_stop_link_train(), leading to modeset failures later as described above. Fix this by setting the training patter to TPS2, if the link training failed at any point. The clue in the specification about the above HW behavior is the explicit mention that TPS2 must be set after the link training sequence (and there isn't a similar requirement specified for the 8b/10b link training), see the Bspec links below. v2: Add bspec aspect/link to the commit log. (Jani) Bspec: 54128, 65448, 68849 Cc: stable@vger.kernel.org # v5.18+ Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250217223828.1166093-2-imre.deak@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-02-19drm/i915/psr: Fix drm_WARN_ON in intel_psr_disableJouni Högander
Currently intel_psr_disable is dumping out warning if PSR is not supported. On monitor supporting only Panel Replay we are seeing this warning. Fix this by checking Panel Replay support as well. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213111628.2183753-1-jouni.hogander@intel.com
2025-02-19drm/i915/display: Allow display PHYs to reset power stateMika Kahola
The dedicated display PHYs reset to a power state that blocks S0ix, increasing idle system power. After a system reset (cold boot, S3/4/5, warm reset) if a dedicated PHY is not being brought up shortly, use these steps to move the PHY to the lowest power state to save power. 1. Follow the PLL Enable Sequence, using any valid frequency such as DP 1.62 GHz. This brings lanes out of reset and enables the PLL to allow powerdown to be moved to the Disable state. 2. Follow PLL Disable Sequence. This moves powerdown to the Disable state and disables the PLL. v2: Rename WA function to more descriptive (Jani) For PTL, only port A needs this wa Add helpers to check presence of C10 phy and pll enabling (Imre) v3: Rename wa function (Imre) Check return value of C10 pll tables readout (Imre) Use PLL request to check pll enabling (Imre) v4: Move intel_cx0_pll_is_enabled() right after intel_cx0_pll_disable() (Imre) Add drm_WARN_ON() if C10 state cannot be calculated from the tables (Imre) v5: Add debug message on PLL enabling (Imre) Add check for intel_encoder_is_dig_port() (Imre) Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250218100019.740556-3-mika.kahola@intel.com
2025-02-19drm/i915/display: Drop crtc_state from C10/C20 pll programmingMika Kahola
For PLL programming for C10 and C20 we don't need to carry crtc_state but instead use only necessary parts of the crtc_state i.e. pll_state. This change is needed to PTL wa 14023648281 where we would need to otherwise pass an artificial crtc_state with majority of the struct members initialized as NULL. v2: Use err instead of val for error handling (Imre) Unify parameter order (Imre) v3: Fix misplaced port_clock, and is_dp in intel_c20_pll_program() call (Imre) Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250218100019.740556-2-mika.kahola@intel.com
2025-02-18drm/i915: Hook up display fault interrupts for VLV/CHVVille Syrjälä
Hook up the display fault irq handlers for VLV/CHV. Unfortunately the actual hardware doesn't agree with the spec on how DPINVGTT should behave. The docs claim that the status bits can be cleared by writing '1' to them, but in reality there doesn't seem to be any way to clear them. So we must disable and ignore any fault we've already seen in the past. The entire register does reset when the display power well goes down, so we can just always re-enable all the bits in irq postinstall without having to track the state beyond that. v2: Use intel_display instead of dev_priv Move xe gen2_error_{init,reset}() out Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250217070047.953-9-ville.syrjala@linux.intel.com
2025-02-18drm/i915: Un-invert {i9xx,i965}_error_mask()Ville Syrjälä
Make life a bit more straightforward by removing the bitwise not from {i9xx,i965}_error_mask() and instead do it when feeding the value to gen2_error_init(). Make life a bit easier I think. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250217070047.953-8-ville.syrjala@linux.intel.com
2025-02-18drm/i915: Introduce i915_error_regsVille Syrjälä
Introduce i915_error_regs as the EIR/EMR counterpart to the IIR/IMR/IER i915_irq_regs, and update the irq reset/postingstall to utilize them accordingly. v2: Include xe compat versions Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250217070047.953-7-ville.syrjala@linux.intel.com Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-02-18drm/i915: Hook in display GTT faults for ILK/SNBVille Syrjälä
Hook up display GTT fault interrupts for ILK/SNB. Bspec: 8559 Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250217070047.953-6-ville.syrjala@linux.intel.com
2025-02-18drm/i915: Hook in display GTT faults for IVB/HSWVille Syrjälä
Dump out the display fault information from the IVB/HSW error interrupt handler. Bspec: 8203 Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250217070047.953-5-ville.syrjala@linux.intel.com
2025-02-18drm/i915: Pimp display fault reportingVille Syrjälä
Decode the display faults a bit more extensively so that one doesn't have to translate the bitmask to planes/etc. manually. Also for plane faults we can read out a bit of state from the relevant plane(s) and dump that out. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250217070047.953-4-ville.syrjala@linux.intel.com
2025-02-18drm/i915: Introduce a minimal plane error stateVille Syrjälä
I want to capture a little bit more information about the state of the plane upon faults. To that end introduce a small plane error state struct and provide per-plane vfuncs to read it out. For now we just stick the CTL, SURF, and SURFLIVE (if available) registers contents in there. v2: Use struct intel_display instead of dev_priv Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250217070047.953-3-ville.syrjala@linux.intel.com
2025-02-18drm/i915: Add missing else to the if ladder in missing elseVille Syrjälä
The if ladder in gen8_de_pipe_fault_mask() was missing one else, add it. Doesn't actually matter since each if branch just returns directly. But the code is less confusing when you always do things the same way. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250217070047.953-2-ville.syrjala@linux.intel.com
2025-02-15drm/i915: s/state/plane_state/Ville Syrjälä
Use the canonical 'plane_state' name for function arguments where appropriate. Also do the s/int plane/int color_plane/ in couple of the function prototypes while at it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213150220.13580-13-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-02-15drm/i915: Relocate some other plane fb related stuff into intel_fb.cVille Syrjälä
Move intel_fb_xy_to_linear() and intel_add_fb_offsets() These are technially sitting somewhere between plane vs. fb code, but we do have a bunch of code like that in intel_fb.c anyway. Might need to think about splitting intel_fb.c into pure fb vs. plane->fb related stuff somehow, but dunno if that's even feasible. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213150220.13580-12-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-02-15drm/i915: Relocate intel_{rotation,remapped}_info_size()Ville Syrjälä
Move intel_{rotation,remapped}_info_size() into intel_fb.c as that seems a slightly better place than intel_display.c. I suppose these should live somewhere outside the display code as they are also used by the gem code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213150220.13580-11-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-02-15drm/i915: Relocate intel_plane_uses_fence()Ville Syrjälä
Relocate intel_plane_uses_fence() into intel_fb.c. Not sure that's the best place, but since this is mostly about the fb and vma I can't think of anything truly better right now. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213150220.13580-10-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
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
generated by cgit (git 2.34.1) at 2025-07-15 11:47:07 +0000