summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)Author
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-17drm/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 (cherry picked from commit 91077d1deb5374eb8be00fb391710f00e751dc4b) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-02-17drm/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 (cherry picked from commit b2ecdabe46d23db275f94cd7c46ca414a144818b) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-02-17drm/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 (cherry picked from commit 76120b3a304aec28fef4910204b81a12db8974da) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-02-17drm/i915/gt: Use spin_lock_irqsave() in interruptible contextKrzysztof Karas
spin_lock/unlock() functions used in interrupt contexts could result in a deadlock, as seen in GitLab issue #13399, which occurs when interrupt comes in while holding a lock. Try to remedy the problem by saving irq state before spin lock acquisition. v2: add irqs' state save/restore calls to all locks/unlocks in signal_irq_work() execution (Maciej) v3: use with spin_lock_irqsave() in guc_lrc_desc_unpin() instead of other lock/unlock calls and add Fixes and Cc tags (Tvrtko); change title and commit message Fixes: 2f2cc53b5fe7 ("drm/i915/guc: Close deregister-context race against CT-loss") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13399 Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com> Cc: <stable@vger.kernel.org> # v6.9+ Reviewed-by: Maciej Patelczyk <maciej.patelczyk@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/pusppq5ybyszau2oocboj3mtj5x574gwij323jlclm5zxvimmu@mnfg6odxbpsv (cherry picked from commit c088387ddd6482b40f21ccf23db1125e8fa4af7e) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-02-17drm/i915/gt: Replace kmap with its safer kmap_local_page counterpartAndi Shyti
kmap_local_page(), unlike kmap(), performs a contextualized mapping of pages. This means the pages are mapped locally to the thread that created them, making them invisible outside the thread and safer to use. Replace kmap() and kunmap() with kmap_local_page() and kunmap_local() counterparts for improved safety. Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Nitin Gote <nitin.r.gote@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250214003437.1311476-1-andi.shyti@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
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-14Merge tag 'drm-misc-next-2025-02-12' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v6.15: UAPI Changes: fourcc: - Add modifiers for MediaTek tiled formats Cross-subsystem Changes: bus: - mhi: Enable image transfer via BHIe in PBL dma-buf: - Add fast-path for single-fence merging Core Changes: atomic helper: - Allow full modeset on connector changes - Clarify semantics of allow_modeset - Clarify semantics of drm_atomic_helper_check() buddy allocator: - Fix multi-root cleanup ci: - Update IGT display: - dp: Support Extendeds Wake Timeout - dp_mst: Fix RAD-to-string conversion panic: - Encode QR code according to Fido 2.2 probe helper: - Cleanups scheduler: - Cleanups ttm: - Refactor pool-allocation code - Cleanups Driver Changes: amdxdma: - Fix error handling - Cleanups ast: - Refactor detection of transmitter chips - Refactor support of VBIOS display-mode handling - astdp: Fix connection status; Filter unsupported display modes bridge: - adv7511: Report correct capabilities - it6505: Fix HDCP V compare - sn65dsi86: Fix device IDs - Cleanups i915: - Enable Extendeds Wake Timeout imagination: - Check job dependencies with DRM-sched helper ivpu: - Improve command-queue handling - Use workqueue for IRQ handling - Add suport for HW fault injection - Locking fixes - Cleanups mgag200: - Add support for G200eH5 chips msm: - dpu: Add concurrent writeback support for DPU 10.x+ nouveau: - Move drm_slave_encoder interface into driver - nvkm: Refactor GSP RPC omapdrm: - Cleanups panel: - Convert several panels to multi-style functions to improve error handling - edp: Add support for B140UAN04.4, BOE NV140FHM-NZ, CSW MNB601LS1-3, LG LP079QX1-SP0V, MNE007QS3-7, STA 116QHD024002, Starry 116KHD024006, Lenovo T14s Gen6 Snapdragon - himax-hx83102: Add support for CSOT PNA957QT1-1, Kingdisplay kd110n11-51ie, Starry 2082109qfh040022-50e panthor: - Expose sizes of intenral BOs via fdinfo - Fix race between reset and suspend - Cleanups qaic: - Add support for AIC200 - Cleanups renesas: - Fix limits in DT bindings rockchip: - rk3576: Add HDMI support - vop2: Add new display modes on RK3588 HDMI0 up to 4K - Don't change HDMI reference clock rate - Fix DT bindings solomon: - Set SPI device table to silence warnings - Fix pixel and scanline encoding v3d: - Cleanups vc4: - Use drm_exec - Use dma-resv for wait-BO ioctl - Remove seqno infrastructure virtgpu: - Support partial mappings of GEM objects - Reserve VGA resources during initialization - Fix UAF in virtgpu_dma_buf_free_obj() - Add panic support vkms: - Switch to a managed modesetting pipeline - Add support for ARGB8888 xlnx: - Set correct DMA segment size - Fix error handling - Fix docs Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250212090625.GA24865@linux.fritz.box
generated by cgit (git 2.34.1) at 2025-07-19 06:49:44 +0000