- 21 Sep, 2023 22 commits
-
-
Ravi Kumar Vodapalli authored
Add Display Power Well for Xe2_LPD. It's mostly the same as Xe_LPD+, so reuse the code. PGPICA1 contains type-C capable port slices which requires the well to power powered up, so add new power well definition for it. The DC_OFF fake power well will be added in a follow up commit. v2: Do not rmw as bit 31 is the only R/W bit in the register (Matt Roper) BSpec: 68886 Signed-off-by:
Ravi Kumar Vodapalli <ravi.kumar.vodapalli@intel.com> Signed-off-by:
Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-20-lucas.demarchi@intel.com
-
Stanislav Lisovskiy authored
Add a new CDCLK table for Lunar Lake. v2: - Remove mdclk from the table as it's not needed (Matt Roper) - Update waveform values to the latest from spec (Matt Roper) - Rename functions and calculation to match by pixel rate (Lucas) v3: Keep only the table: as far as intel_pixel_rate_to_cdclk() is concerned, the minimum cdclk should still be half the pixel rate on Xe2 (bspec 68858: "Pipe maximum pixel rate = 2 * CDCLK frequency * Pipe Ratio") (Matt Roper) Bspec: 68861, 68858 Signed-off-by:Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Lucas De Marchi authored
LNL's south display uses the same table as MTP. Check for LNL's fake PCH to make it consistent with the other checks. The VBT table doesn't contain the VBT -> spec mapping for LNL. Like in other cases, uses the same as the previous platform. Bspec: 68971, 20124 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
-
Lucas De Marchi authored
Xe2_LPD also needs workaround 15010685871. While adding the new display version, also re-order the condition to follow the convention of new version first. v2: Remove redundant HAS_CDCLK_SQUASH(). As the platform or IP version needing the workaround are handpicked, there is no need to also check if tha platform has squashing support (Matt Roper) Signed-off-by: -
Gustavo Sousa authored
Hotplug setup for Xe2_LPD differs from Xe_LPD+ by the fact that the extra programming for hotplug inversion and DDI HPD filter duration is not necessary anymore. As mtp_hpd_irq_setup() is reasonably small, prefer to fork it into a new function for Xe2_LPD instead of adding a platform check. v2: Add extra bspec reference and fix missing else (Matt Roper) BSpec: 68970, 69940 Signed-off-by:
-
Juha-Pekka Heikkilä authored
Enable odd size and panning for planar yuv formats. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by:
Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Reviewed-by:
Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by:
-
Luca Coelho authored
Starting from display version 20, we need to read the pin assignment from the IOM TCSS_DDI_STATUS register instead of reading it from the FIA. We use the pin assignment to decide the maximum lane count. So, to support this change, add a new lnl_tc_port_get_max_lane_count() function that reads from the TCSS_DDI_STATUS register and decides the maximum lane count based on that. BSpec: 69594 Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Reviewed-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
-
Gustavo Sousa authored
Differently from previous version, Xe2_LPD groups all port AUX interrupt bits into PICA interrupt registers. While at it, drop some trailing newlines. BSpec: 68958, 69697 Signed-off-by:
-
Lucas De Marchi authored
The address of CTL and DATA registers for DP AUX were changed in Xe2_LPD: now they are all in a single range, with CH_A and CH_B coming right after the USBC instances. Like was done when moving registers to PICA, use a helper macro to remap the ch passed to an index that can be used to calculate the right offset. Signed-off-by:
-
Lucas De Marchi authored
XELPDP_DP_AUX_CH_CTL() and XELPDP_DP_AUX_CH_DATA() use 2 ranges. Prefer using _PICK_EVEN_2RANGES() over PICK(). Signed-off-by:
-
Lucas De Marchi authored
Fix some whitespace issues for register definitions and keep the defines for DP_AUX_CH_CTL and DP_AUX_CH_DATA in the right place: together with the bit definition. While at it add a TODO entry that those defines shouldn't be using an implicit dev_priv. Signed-off-by:
-
Clint Taylor authored
Do not read DE_RRMR register after display version 20. This register contains display state information during GFX state dumps. Bspec: 69456 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by:
Clint Taylor <clinton.a.taylor@intel.com> Reviewed-by:
-
Matt Roper authored
Since Xe2LPD technically has FlatCCS, it doesn't have AuxCCS registers like PLANE_AUX_DIST. However we currently have HAS_FLAT_CCS hardcoded to 0 since compression isn't ready; we need to make sure this doesn't cause the display code to go back to trying to write this register. Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-8-lucas.demarchi@intel.com
-
Stanislav Lisovskiy authored
We now start calculating relative plane data rate for cursor plane as well, as instructed by BSpec and also treat cursor plane same way as other planes, when doing allocation, i.e not using fixed allocation for cursor anymore. Bspec: 68907 Signed-off-by:
-
Gustavo Sousa authored
Xe2_LPD doesn't have south display engine on a PCH, it's actually on the SoC die (while north display engine is on compute die). As such it makes no sense to go through the PCI devices looking for an ISA bridge. The approach used by BXT/GLK can't be used here since leaving it with PCH_NONE would mean taking the wrong code paths. For the places we currently use a PCH check, it's enough for now to just check the north display version. Use that to define a fake PCH to be used across the driver. Eventually these PCH checks may need to be re-designed as this is already the third platform using/needing a fake PCH. v2: Match on display IP version rather than on platform (Matt Roper) v3: Extend and clarify commit message (Matt Roper / Ville) Signed-off-by:
-
Lucas De Marchi authored
Follow the convention of checking the last platform first and reword the comment to convey there are more platforms than just DG1. Reviewed-by:
-
Clint Taylor authored
If a particular pipe is disabled by fuse also remove the FBC for that pipe. Bspec: 69464 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by:
Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by:
-
Matt Roper authored
FBC is no longer limited by pipe: add the defines for pipes B and C that will be used by platforms supporting FBC on such pipes. Bspec: 68881, 68904 Signed-off-by:
-
Balasubramani Vivekanandan authored
Add Lunar Lake platform definitions for i915 display. The support for LNL will be added to the xe driver, with i915 only driving the display side. Xe2 display is derived from the Xe_LPD+ IP; additional feature deltas will be introduced in subsequent patches, so here it's just adding a separate xe2_lpd_display struct. v2: Use a LPDP_FEATURES macro (Matt Roper) Signed-off-by:
Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Signed-off-by:
-
Lucas De Marchi authored
Add a FEATURES macro for XE_LPD+ as this is expected to be the baseline for Xe2_LPD and will allow to see the delta more easily. v2: Move everything from xe_lpdp_display to the new macro and remove the version setting: it's not needed with GMD_ID. Signed-off-by: -
Ville Syrjälä authored
This reverts commit 959fb1a6. Looks like the core MST code might not call i2c_adapter() for us in time, and thus creating the ddc symlink will fail. This will in fact fail the entire connector registration, but the MST code doesn't really seem to care about that and blindly plows ahead. All we may get in the logs is a nearly back to back register+unregister debug messages: [drm:drm_dp_mst_connector_late_register [drm_display_helper]] registering DPMST remote bus for card0-DP-7 [drm:intel_dp_hpd_pulse [i915]] DPRX ESI: 42 00 00 02 [drm:drm_dp_mst_connector_early_unregister [drm_display_helper]] unregistering DPMST remote bus for card0-DP-7 Untangling the initialization order may take some real work, so let's just revert the ddc symlink addition for now... Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9357 Fixes: 959fb1a6 ("drm/i915/mst: Populate connector->ddc") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919095659.10742-1-ville.syrjala@linux.intel.comAcked-by:
Jani Nikula <jani.nikula@intel.com> Tested-by:
Karthik B S <karthik.b.s@intel.com>
-
Jani Nikula authored
Add a note that fec_enable actually means FEC is to be enabled explicitly. 128b/132b always has FEC enabled, the driver doesn't need to enable it separately, and fec_enable will be false. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
- 20 Sep, 2023 13 commits
-
-
Ville Syrjälä authored
Implement low refresh rate (LRR) where we change the vblank length by hand as requested, but otherwise keep the timing generator running in non-VRR mode (ie. fixed refresh rate). The panel itself must support VRR for this to work, and only TGL+ has the double buffred TRANS_VTOTAL.VTOTAL that we need to make the switch properly. The double buffer latching happens at the start of transcoders undelayed vblank. The other thing that we change is TRANS_VBLANK.VBLANK_END but the hardware entirely ignores that in DP mode. But I decided to keep writing it anyway just to avoid more special cases in readout/state check. v2: Document that TRANS_VBLANK.VBLANK_END is ignored by the hardware v3: Reconcile with VRR fastset Adjust update_lrr flag behaviour Make sure timings stay within VRR range v4: Fix up update_m_n vs. update_lrr rebase fail (Manasi) Drop DOUBLE_BUFFER_VACTIVE define as it's not needed (Manasi) TODO: Hook LRR into the automatic DRRS downclocking stuff? Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by:Manasi Navare <navaremanasi@chromium.org>
-
Ville Syrjälä authored
Whenever we change the actual transcoder timings (clock via seamless M/N, full modeset, (or soon) vtotal via LRR) we want the timing generator to be in non-VRR during the commit. Warn if we forgot to turn VRR off prior to vblank evasion. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by:
Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
-
Ville Syrjälä authored
We should be able to change any of the VRR parameters during fastsets as long as we toggle VRR off at the start and then back on at the end. The transcoder will be running in non-VRR mode during the transition. Co-developed-by:
Sean Paul <seanpaul@chromium.org>
-
Ville Syrjälä authored
Make life less confusing by making sure VRR is disabled whenever we do any drastic changes to the display timings, such as seamless M/N changes. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by:
-
Ville Syrjälä authored
Let's assume there are some crazy displays where the high end of the VRR range ends up being lower than the refresh rate as determined by the actual timings. In that case when we toggle VRR on/off we would step outside the VRR range when toggling VRR on/off. Let's just make sure that never happens by not using VRR in such cases. If the user really wants VRR they should then select the timings to land within the VRR range. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by:
-
Ville Syrjälä authored
Move is_in_vrr_range() into intel_vrr.c in anticipation of more users, and rename it accordingly. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by:
-
Ville Syrjälä authored
Don't perform a seamless M/N update if the values aren't actually changing. This avoids doing extra shenanigans during vblank evasion needlessly. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by:
-
Ville Syrjälä authored
Make the seamless_m_n flag more like the update_pipe fastset flag, ie. the flag will only be set if we need to do the seamless M/N update, and in all other cases the flag is cleared. Also rename the flag to update_m_n to make it more clear it's similar to update_pipe. I believe special casing seamless_m_n like this makes sense as it also affects eg. vblank evasion. We can potentially avoid some vblank evasion tricks, simplify some checks, and hopefully will help with the VRR vs. M/N mess. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by:
-
Ville Syrjälä authored
In order to reconcile seamless M/N updates with VRR we'll need to defer the fastset VRR enable to happen after the seamless M/N update (which happens during the vblank evade critical section). So just push the VRR enable to be the last thing during the update. This will also affect the vblank evasion as the transcoder will now still be running with the old VRR state during the vblank evasion. So just grab the timings always from the old crtc state during any non-modeset commit, and also grab the current state of VRR from the active timings (as we disable VRR before vblank evasion during fastsets). This also fixes vblank evasion for seamless M/N updates as we now properly account for the fact that the M/N update happens after vblank evasion. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by:
-
Ville Syrjälä authored
Pull the vblank evasion scanline calculations into their own helper to declutter intel_pipe_update_start() a bit. Reviewed-by:
-
Ville Syrjälä authored
We'll need to also look at the old crtc state in intel_pipe_update_start() so change the calling convention to just plumb in the full atomic state instead. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by:
-
Ville Syrjälä authored
Do the PSR unlock after the vblank evade critcal section is fully over, not before. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by:
-
William Tseng authored
This change is to adjust TCLK-POST timing so DSI signaling can meet CTS specification. For clock lane, the TCLK-POST timing may be changed from 133.44 ns to 178.72 ns, which is greater than (60 ns+52*UI) and is conformed to the CTS standard. The computed UI is around 1.47 ns. v2: remove the change of HS-TRAIL. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Lee Shawn C <shawn.c.lee@intel.com> Signed-off-by:
William Tseng <william.tseng@intel.com> Signed-off-by:
-
- 18 Sep, 2023 3 commits
-
-
Gustavo Sousa authored
There was a recent update in the BSpec adding an extra step to the PLL enable sequence, which is for programming the msgbus timer. Since we also touch PHY registers during hw readout, let's do the programming when starting a transaction rather than only when doing the PLL enable sequence. This might be the missing step that was causing the timeouts that we have recently seen during C20 SRAM register programming sequences. With this in place, we shouldn't need the logic to bump the timer thresholds, since now we have a documented value that should be set peform programming the registers. As such, let's also remove intel_cx0_bus_check_and_bump_timer(), but keep the part that checks if hardware really detected a timeout, which might be useful debugging information. v2: - Use debug level instead of warning for the message notifying that the hardware did not detect the timeout. (Mika) - Got a new BSpec update clarifying that we need to program the msgbus timer of both PHY lanes. Update the changes to reflect that. (Gustavo) BSpec: 64568 Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: -
Imre Deak authored
If a sink is removed in the middle of payload addition drm_dp_add_payload_part1() will fail as expected, either not finding the payload's MST port or failing the payload-add AUX transaction. Based on the above tune the error message down to a debug messge. Cc: Lyude Paul <lyude@redhat.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230913223218.540365-4-imre.deak@intel.com
-
Jouni Högander authored
It's not necessary to carry separate suspended status information in intel_runtime_pm struct as this information is already in underlying device structure. Remove it and use pm_runtime_suspended() to obtain suspended status information when needed. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Jouni Högander <jouni.hogander@intel.com> Acked-by:
-
- 15 Sep, 2023 2 commits
-
-
Jani Nikula authored
Don't hide display probe in device info code. Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230912120537.2158209-3-jani.nikula@intel.com
-
Jani Nikula authored
Move gmdid selection one abstraction level higher. Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
