- 22 Jul, 2024 1 commit
-
-
Imre Deak authored
Instead of direct calls of the link training functions, use a modeset commit to retrain a DP link in SST mode, similarly to how this is done in DP-MST mode. Originally the current way was chosen presumedly, because there wasn't a well-established way in place for the driver to do an internal (vs. userspace/kernel client) commit. Since then such internal commits became a common place (initial-, HDMI/TC link reset commit), so there is no reason to handle the DP-SST link-retraining case differently. At the end of the current sequence the HW reported a FIFO underrun - without other issues visible to users - because during retraining the link's encoder/port was disabled/re-enabled without also disabling/re-enabling the corresponding pipe/transcoder (as required by the spec); the corresponding underrun error message was suppressed as a known issue. Based on Ankit's test on DG2 the underrun error was still reported as it got detected with some (vblank) delay wrt. other platforms. Switching to a modeset commit resolves these underrun related issues. Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240712135724.660399-1-imre.deak@intel.com
-
- 12 Jul, 2024 15 commits
-
-
Ville Syrjälä authored
Extract a helper to determine the CFB bytes per pixel value. Currently this is always 4, but that could change in the future. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240705145254.3355-14-ville.syrjala@linux.intel.comReviewed-by:
Uma Shankar <uma.shankar@intel.com>
-
Ville Syrjälä authored
Pull the lower level stuff out from intel_fbc_cfb_size() into a separate function that doesn't depend on the plane_state. Signed-off-by:
-
Ville Syrjälä authored
Pull the code to determine the maximum CFB height into a separate function. To make this work we need to declare an explicit max height for all older platforms as well. But that is actually just the max plane height as pre-HSW hardware supposedly doesn't have the trick of leaving the extra lines uncompressed. Signed-off-by:
-
Ville Syrjälä authored
Rearrange the max CFB max height platform into the more common "new first, old last" order. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Ville Syrjälä authored
Use the more customary name 'height' instead of 'lines'. Signed-off-by:
-
Ville Syrjälä authored
Pull the lower level stuff out from intel_fbc_cfb_stride() into a separate function that doesn't depend on the plane_state. Signed-off-by:
-
Ville Syrjälä authored
Do the "is this ilk+ or g4x" checks in the customary order instead of the reverse order. Easier for the poor brain to parse this when it's always done the same way. Signed-off-by:
-
Ville Syrjälä authored
Rename intel_fbc_hw_tracking_covers_screen() to intel_fbc_surface_size_ok() so that the naming scheme is the same for the surface size vs. plane size checks. "surface size" is what bspec talks about. Signed-off-by:
-
Ville Syrjälä authored
Extract intel_fbc_max_surface_size() from intel_fbc_hw_tracking_covers_screen(), mainly to mirror the "max plane size" counterparts. Signed-off-by:
-
Ville Syrjälä authored
Extract intel_fbc_max_plane_size() from intel_fbc_plane_size_valid(). We'll have another use for this soon in determining how much stolen memory we'd like to keep reserved for FBC. Signed-off-by:
-
Ville Syrjälä authored
_intel_fbc_cfb_stride() calculates the CFB stride the hardware would automagically generate from the plane's stride. Rename the function to intel_fbc_plane_cfb_stride() to better reflect its purpose. Signed-off-by:
-
Ville Syrjälä authored
Switch the FBC code over to intel_display from i915, as much as possible. This is the future direction so that the display code can be shared between i915 and xe more cleanly. Some of the platform checks and the stolen mem facing stiff still need i915 around though. v2: Drop some redundant to_i915() casts Signed-off-by:
-
Ville Syrjälä authored
Pull the "do we have fences?" check into a single helper in the FBC code. Avoids having to call to outside the display code in multiple places for this. Signed-off-by:
-
Ville Syrjälä authored
Give vrr_enabling() and vrr_disabling() slightly fancier names, and pass in the whole atomic state so that they'll be easier to use. We'll need to call at least the disabling part from the DSB code soon enough (so that we can do vblank evasions/etc. correctly on the DSB). Signed-off-by:
Animesh Manna <animesh.manna@intel.com>
-
Ville Syrjälä authored
Calculate the vblank delay in the vblank evasion code correctly for interlaced modes. The current code assumes that we won't be using an interlaced mode. That assumption is actually valid since we've defeatured interlaced scanout in commit f71c9b7b ("drm/i915/display: Prune Interlace modes for Display >=12") for DSB capable platforms. However the feature is still present in the hardware, and if we ever find the need to re-enable it seems better to calculate the vblank delay correctly. Signed-off-by:
-
- 11 Jul, 2024 4 commits
-
-
Imre Deak authored
Nothing depends on the cached LTTPR mode, however for consistency keep it up-to-date with the value programmed to the DPCD register. Reviewed-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
-
Imre Deak authored
After detection the cached LTTPR count can be checked to determine if LTTPRs in non-transparent mode were detected. Reset the cached LTTPR count if the reported number of LTTPRs is invalid to ensure the above checks work as expected. Reviewed-by:
-
Imre Deak authored
Switching to transparent mode leads to a loss of link synchronization, so prevent doing this on an active link. This happened at least on an Intel N100 system / DELL UD22 dock, the LTTPR residing either on the host or the dock. To fix the issue, keep the current mode on an active link, adjusting the LTTPR count accordingly (resetting it to 0 in transparent mode). v2: Adjust code comment during link training about reiniting the LTTPRs. (Ville) Fixes: 7b2a4ab8 ("drm/i915: Switch to LTTPR transparent mode link training") Reported-and-tested-by:
Gareth Yu <gareth.yu@intel.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10902 Cc: <stable@vger.kernel.org> # v5.15+ Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Imre Deak authored
Regularly retraining a link during an atomic commit happens with the given pipe/link already disabled and hence intel_dp->link_trained being false. Ensure this also for retraining a DP SST link via direct calls to the link training functions (vs. an actual commit as for DP MST). So far nothing depended on this, however the next patch will depend on link_trained==false for changing the LTTPR mode to non-transparent. Cc: <stable@vger.kernel.org> # v5.15+ Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
- 10 Jul, 2024 1 commit
-
-
Mitul Golani authored
The dispcnlunit1_cp_xosc_clk should be de-asserted in display off and only asserted in display on. As part of this workaround, Display driver shall execute set-reset sequence at the end of the initialize sequence to ensure clk does not remain active in display OFF. --v2: - Rebase. --v3: - Correct HSD number in commit message. --v4: - Reformat commit message. - Use intel_de_rmw instead of intel_de_write --v5: - Build Fixes. WA: 15013987218 Signed-off-by:
Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by:
Nemesa Garg <nemesa.garg@intel.com> Reviewed-by:
-
- 09 Jul, 2024 1 commit
-
-
Mitul Golani authored
Add new member to struct intel_dp to cache support of Adaptive Sync SDP capabilities and use it whenever required to avoid HW access to read capability during each atomic commit. -v2: - Squash both the patches Signed-off-by:
Arun R Murthy <arun.r.murthy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240704082638.2302092-2-mitulkumar.ajitkumar.golani@intel.comSigned-off-by:
-
- 01 Jul, 2024 1 commit
-
-
Gustavo Sousa authored
Starting with Xe_LPD+, although FIA is still used to readout Type-C pin assignment, part of Type-C support is moved to PICA and programming PORT_TX_DFLEXDPMLE1(*) registers is not applicable anymore like it was for previous display IPs (e.g. see BSpec 49190). v2: - Mention Bspec 49190 as a reference of instructions for previous IPs. (Shekhar Chauhan) - s/Xe_LPDP/Xe_LPD+/ in the commit message. (Matt Roper) - Update commit message to be more accurate to the changes in the IP. (Imre Deak) Bspec: 65750, 65448 Reviewed-by:Shekhar Chauhan <shekhar.chauhan@intel.com> Reviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com>
-
- 28 Jun, 2024 1 commit
-
-
Imre Deak authored
In TBT-alt mode the driver doesn't program the PHY's PLL, which is handled instead by Thunderbolt driver/FW components, hence the PLL's HW vs. SW state verification should be skipped. During HW readout set a flag in the PLL state if the port was at the moment in TBT-alt mode and skip the verification of PLL parameters in this case. Fixes: 45fe957a ("drm/i915/display: Add compare config for MTL+ platforms") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11258 Cc: Mika Kahola <mika.kahola@intel.com> Reviewed-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
-
- 27 Jun, 2024 1 commit
-
-
Ville Syrjälä authored
DSB_STATUS bit 16 is supposed to be a sticky bit informing us whether the DSB was idle or not when the pipe's delayed vblank (when double buffered registers latch) occurred. Unfortunately it turns out this is a level triggred signal, ie. the bit will be set whenever the DSB is busy during the scanline window between start of delayed vblank and vtotal. Try to document that fact by renaming the bit. Sadly this also thwarts my plan to use this bit to sanity check that the (to be introduced) DSB based vblank evasion did its job correctly. That would require an edge triggered signal instead. So looks like we'll have to rely mostly on luck instead :( Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
- 26 Jun, 2024 1 commit
-
-
Imre Deak authored
For MTL+ platforms we use PICA chips for Type-C support and hence mg programming is not needed. Fixes issue with drm warn of TC port not being in legacy mode. Cc: stable@vger.kernel.org Signed-off-by:
-
- 25 Jun, 2024 11 commits
-
-
Jouni Högander authored
There are couple of bits in PSR2_CTL which needs to be written in case of eDP Panel Replay Bspec: 68920 v2: use boolean instead of assuming eDP Panel Replay mean Early Transport Signed-off-by:
Jouni Högander <jouni.hogander@intel.com> Reviewed-by:
-
Jouni Högander authored
Move Early Transport validity check to be performed for Panel Replay as well and use Early Transport for eDP Panel Replay always. v2:set crtc_state->enable_psr2_su_region_et directly (not in if block) Signed-off-by:
-
Jouni Högander authored
Scanline indication needs to be checked and configure for both PSR2 and Panel Replay Selective Update. Move this check to intel_sel_update_config_valid. Signed-off-by:
-
Jouni Högander authored
eDP1.5 support ALPM with Panel Replay as well. We need to check ALPM related things for Panel Replay as well. Bspec: 68920 v5: - instead of using crtc_state->has_panel_replay provide aux_less flag v4: - do not move _compute_psr2_sdp_prior_scanline_indication - move ALPM related checks to separate function v3: move vblank check as well v2: do not move Vblank >= PSR2_CTL Block Count Number maximum line count check Signed-off-by: -
Jouni Högander authored
Intel_alpm_compute_params doesn't change crtc_state. Let's convert it as const. Signed-off-by:
-
Jouni Högander authored
Take into account in Panel Replay compute config that HW will not allow PR on eDP when HDCP enabled. v2: add debug message to print out why Panel Replay is not possible Signed-off-by:
-
Jouni Högander authored
Take into account that 128b/132b Panel Replay is not supported on eDP. Bspec: 68920 v2: - make crtc_state as const - add debug message to print out why Panel Replay is not possible Signed-off-by:
-
Jouni Högander authored
Our HW doesn't support panel replay without Early Transport on eDP. Bspec: 68920 Signed-off-by:
-
Jouni Högander authored
eDP1.5 allows Panel Replay on eDP as well. Take this into account when enabling sink PSR/Panel Replay. Write also PANEL_REPLAY_CONFIG2 register accordingly. v3: - set DP_PANEL_REPLAY_CRC_VERIFICATION in PANEL_REPLAY_CONFIG2 - PANEL_REPLAY_CONFIG2 is available in DP2.1 as well v2: do not configure ALPM for DP2.0 Panel Replay Signed-off-by:
-
Jouni Högander authored
Display version >= 20 support eDP 1.5. Inform Panel Replay source support on eDP for display version >= 20. Bspec: 68920 Signed-off-by:
-
Jouni Högander authored
Our HW doesn't support Panel Replay without AUX_LESS ALPM on eDP. Check panel support for this and prevent eDP panel replay if it doesn't exits. Bspec: 68920 v3: remove excessive parens v2: use intel_alpm_aux_less_wake_supported Signed-off-by:
-
- 24 Jun, 2024 3 commits
-
-
Maarten Lankhorst authored
In case of legacy cursor update, the cursor VMA needs to be unpinned only after vblank. This exceeds the lifetime of the whole atomic commit. Any trick I attempted to keep the atomic commit alive didn't work, as drm_atomic_helper_setup_commit() force throttles on any old commit that wasn't cleaned up. The only option remaining is to remove the plane from the atomic commit, and use the same path as the legacy cursor update to clean the state after vblank. Changes since previous version: - Call the memset for plane state immediately when scheduling vblank, this prevents a use-after-free in cursor cleanup. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
-
Ville Syrjälä authored
The cursor hardware only does sync updates, and thus the hardware will be scanning out from the old fb until the next start of vblank. So in order to make the legacy cursor fastpath actually safe we should not unpin the old fb until we're sure the hardware has ceased accessing it. The simplest approach is to just use a vblank work here to do the delayed unpin. Not 100% sure it's a good idea to put this onto the same high priority vblank worker as eg. our timing critical gamma updates. But let's keep it simple for now, and it we later discover that this is causing problems we can think about adding a lower priority worker for such things. This patch is slightly reworked by Maarten Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Maarten Lankhorst authored
In some cases we want to flush all vblank work, right before vblank_off for example. Add a simple function to make this possible. Check that both pending_work and running work are empty when flushing. Co-Developed-by:
Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by:
-
