- 28 Sep, 2023 9 commits
-
-
Imre Deak authored
At the moment a modeset fails if the config computation of a pipe can't fit its required BW to the available link BW even though the limitation may be resolved by reducing the BW requirement of other pipes. To improve the above this patch adds helper functions checking the overall BW limits after all CRTC states have been computed. If the check fails the maximum link bpp for a selected pipe will be reduced and all the CRTC states will be recomputed until either the overall BW limit check passes, or further bpp reduction is not possible (because all pipes/encoders sharing the link BW reached their minimum link bpp). Atm, the MST encoder allocates twice the required BW for YUV420 format streams. A follow-up patchset will fix that, add a code comment about this. This change prepares for upcoming patches enabling the above BW management on FDI and MST links. v2: - Rename intel_crtc_state::max_link_bpp to max_link_bpp_x16 and intel_link_bw_limits::max_bpp to max_bpp_x16. (Jani) v3: - Add the helper functions in a separate patch. (Ville) - Add the functions to intel_link_bw.c instead of intel_atomic.c (Ville) - Return -ENOSPC instead of -EINVAL to userspace in case of a link BW limit failure. v4: - Make intel_atomic_check_config() static. v5: (Ville) - Rename intel_link_bw_limits::min_bpp_pipes to min_bpp_reached_pipes and intel_link_bw_reset_pipe_limit_to_min() to intel_link_bw_set_min_bpp_for_pipe(). - Rename pipe_bpp to link_bpp in intel_link_bw_reduce_bpp(). - Add FIXME: comment about MST encoder's YUV420 BW allocation and tracking the link bpp limit accordingly. v6: - Move intel_link_bw_compute_pipe_bpp() to intel_fdi.c (Ville) - WARN_ON(BIT(pipe) & min_bpp_reached_pipes) in intel_link_bw_set_bpp_limit_for_pipe(). (Ville) - Rename intel_link_bw_set_min_bpp_for_pipe() to intel_link_bw_set_bpp_limit_for_pipe() and intel_link_bw_limits::min_bpp_reached_pipes to bpp_limit_reached_pipes. (Ville) - Remove unused header includes. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230921195159.2646027-10-imre.deak@intel.com
-
Imre Deak authored
Factor out intel_atomic_check_config() to check and compute all the CRTC states. This will be used by a follow up patch to recompute/check the state until required by BW limitations between CRTCs. Reviewed-by:
-
Imre Deak authored
Rename intel_modeset_all_pipes() to intel_modeset_all_pipes_late() to clarify when the function can be called (vs. intel_modeset_pipes_in_mask_early()). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Imre Deak authored
Add intel_modeset_pipes_in_mask_early() to modeset a provided set of pipes, used in a follow-up patch. As opposed to intel_modeset_all_pipes() which modesets only the active pipes - others don't requiring programming the HW - modeset all enabled pipes in intel_modeset_pipes_in_mask_early() which may need to recompute their state even if they are not active (that is in the DPMS off state). While at it add DocBook descriptions for the two exported functions. v2: - Add a flag controlling if active planes are force updated as well. - Add DockBook descriptions. v3: - For clarity use _early/_late suffixes for the exported functions instead of the update_active_planes parameter. (Ville) v4: - In intel_modeset_pipes_in_mask_early() update only the crtc flags relevant to the early phase. (Ville) - Rename intel_modeset_all_pipes() in a separate patch. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Imre Deak authored
Limit the output link bpp in DSC mode to the link_config_limits link.min_bpp_x16 .. max_bpp_x16 range the same way it's done in non-DSC mode. Atm this doesn't make a difference, the link bpp range being 0 .. max pipe bpp, but a follow-up patch will need a way to reduce max link bpp below its current value. v2: - Add to_bpp_int_roundup() instead of open coding it. (Jani) Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
-
Imre Deak authored
In non-DSC mode the link bpp can be set in 2*3 bpp steps in the pipe bpp range, while in DSC mode it can be set in 1/16 bpp steps to any value up to the maximum pipe bpp. Update the limits accordingly in both modes to prepare for a follow-up patch which may need to reduce the max link bpp value and starts to check the link bpp limits in DSC mode as well. While at it add more detail to the link limit debug print and print it also for DSC mode. v2: - Add to_bpp_frac_dec() instead of open coding it. (Jani) v3: (Ville) - Add BPP_X16_FMT / BPP_X16_ARG. - Add TODO: comment about initializing the DSC link bpp limits earlier. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Imre Deak authored
Computing the non-DSC mode link config is redundant once it's determined that DSC will be needed, so skip computing it. In a follow-up patch this simplifies setting the link limits which are dependent on the DSC vs. non-DSC mode. While at it sanitize the debug print about the MST DSC fallback path, making it similar to the SST DSC one. Reviewed-by:
-
Imre Deak authored
A follow-up patch will need to limit the output link bpp both in the non-DSC and DSC configuration, so track the pipe and link bpp limits separately in the link_config_limits struct. Use .4 fixed point format for link bpp matching the 1/16 bpp granularity in DSC mode and for now keep this limit matching the pipe bpp limit. v2: (Jani) - Add to_bpp_int(), to_bpp_x16() helpers instead of opencoding them. - Rename link_config_limits::link.min/max_bpp to min/max_bpp_x16. Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
Luca Coelho <luciano.coelho@intel.com> Reviewed-by:
-
Imre Deak authored
Factor out helpers that DP / DP_MST encoders can use to compute the link rate/lane count and bpp limits. A follow-up patch will call these to recalculate the limits if DSC compression is required. Reviewed-by:
-
- 27 Sep, 2023 13 commits
-
-
Ville Syrjälä authored
Normally we could be in a deep PkgC state all the way up to the point when DSB starts its execution at the transcoders undelayed vblank. The DSB will then have to wait for the hardware to wake up before it can execute anything. This will waste a huge chunk of the vblank time just waiting, and risks the DSB execution spilling into the vertical active period. That will be very bad, especially when programming the LUTs as the anti-collision logic will cause DSB to corrupt LUT writes during vertical active. To avoid these problems we can instruct the DSB to pre-wake the display engine on a specific scanline so that everything will be 100% ready to go when we hit the transcoder's undelayed vblank. One annoyance is that the scanline is specified as just that, a single scanline. So if we happen to start the DSB execution after passing said scanline no DEwake will happen and we may drop back into some PkgC state before reaching the transcoder's undelayed vblank. To prevent that we'll use the "force DEwake" bit to manually force the display engine to stay awake. We'll then have to clear the force bit again after the DSB is done (the force bit remains effective even when the DSB is otherwise disabled). Signed-off-by:
Uma Shankar <uma.shankar@intel.com>
-
Ville Syrjälä authored
Add a helper to convert our idea of a scanline to the hw's idea of the same scanline (ie. apply crtc->scanline_offset in reverse). We'll need this to tell the DSB do stuff on a specific scanline. Signed-off-by:
-
Ville Syrjälä authored
The DSB code will want to know the maximum PkgC latency it has to contend with. Add a helper to expose that information. Signed-off-by:
-
Ville Syrjälä authored
We want to start the DSB execution from the transcoder's undelayed vblank, so in order to guarantee atomicity with the all the other mmio register writes we need to evade both vblanks. Note that currently we don't add any vblank delay, so this is effectively a nop. But in the future when we start to program double buffered registers from the DSB we'll need to delay the pipe's vblank to provide the register programming "window2" for the DSB. Signed-off-by:
-
Ville Syrjälä authored
The DSB has problems writing the legacy LUT. The two workarounds I've discoverted are: - write each entry twice back to back - use non-posted writes Let's use non-posted writes as that seems a bit more standard. TODO: measure which is faster Signed-off-by:
-
Ville Syrjälä authored
Loading LUTs with the DSB outside of vblank doesn't really work due to the palette anti-collision logic. Apparently the DSB register writes don't get stalled like CPU mmio writes do and instead we end up corrupting the LUT entries. Disabling the anti-collision logic would allow us to successfully load the LUT outside of vblank, but presumably that risks the LUT reads from the scanout (temporarily) getting corrupted data from the LUT instead. The anti-collision logic isn't active during vblank so that is when we can successfully load the LUT with the DSB. That is what we want to do anyway to avoid tearing. Signed-off-by:
-
Ville Syrjälä authored
Using the DSB for LUT loading during full modesets would require some actual though. Let's just use mmio for the time being. Signed-off-by:
-
Ville Syrjälä authored
Writing specific transcoder registers (and as it turns out, the legacy LUT as well) via DSB needs a magic sequence to emit non-posted register writes. Add a helper for this. Signed-off-by:
-
Ville Syrjälä authored
Add a function for emitting masked register writes. Note that the mask is implemented through byte enables, so can only mask off aligned 8bit sets of bits. Signed-off-by:
-
Ville Syrjälä authored
Add a helper for emitting a number of DSB NOOPs commands. Signed-off-by:
-
Ville Syrjälä authored
Add some defines to specify what goes inside certain DSB instructions. Signed-off-by:
-
Ville Syrjälä authored
Define all the DSB register bits so I don't have to look through bspec to find them. Signed-off-by:
-
Ville Syrjälä authored
Avoid the locking overhead for DSB registers. We don't need the locks and intel_dsb_commit() in particular needs to be called from the vblank evade critical section and thus needs to be fast. Signed-off-by:
-
- 26 Sep, 2023 2 commits
-
-
Jani Nikula authored
Avoid including the world from headers when forward declarations suffice. Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230921155325.3851197-1-jani.nikula@intel.com
-
Jani Nikula authored
Convert aux_ch_name() to a helper that prints a string to a caller provided buffer, and use it to get more consistent aux channel debugs. Now that all users of aux_ch_name() are in intel_dp_aux.c, we can make it static too. Signed-off-by:
Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230922105645.3991066-1-jani.nikula@intel.com
-
- 25 Sep, 2023 2 commits
-
-
Gustavo Sousa authored
Starting with Xe_LP+, GFX_MSTR_IRQ contains status bits that have W1C behavior. If we do not properly reset them, we would miss delivery of interrupts if a pending bit is set when enabling IRQs. As an example, the display part of our probe routine contains paths where we wait for vblank interrupts. If a display interrupt was already pending when enabling IRQs, we would time out waiting for the vblank. Avoid the potential issue by clearing GFX_MSTR_IRQ as part of the IRQ reset. v2: - Move logic from gen11_gt_irq_reset() to dg1_irq_reset(). (Matt) BSpec: 50875, 54028 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230920195351.59421-2-gustavo.sousa@intel.com
-
Tvrtko Ursulin authored
Recent refactoring left an unsightly block of empty lines. Remove them. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
-
- 22 Sep, 2023 1 commit
-
-
Balasubramani Vivekanandan authored
Separate the printing of display version and feature flags from the main driver probe to inside the display initialization. This is in alignment with isolating the display code from the main driver and helps Xe driver to resuse it. v2: Replace drm_info_printer with drm_debug_printer (Jani) Signed-off-by:
Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230921105954.2002469-1-balasubramani.vivekanandan@intel.com
-
- 21 Sep, 2023 13 commits
-
-
Ville Syrjälä authored
We have the same h/vsync_end vs. h/vtotal quirk in the VBT parser that was also present in EDID parser. Adjust the VBT parser the same way as was done for hte EDID parser to fixup h/vsync_end instead of h/vtotal. While I'm not currently aware of any machines that need this for the VBT it seems prudent to keep both parsers in sync. And while at it let's add some debugs here as well. A bit lackluster but didn't feel like plumbing the connector all the way down at this time. Signed-off-by:
-
Stanislav Lisovskiy authored
Introduce correspondent definitions for choosing between CD2X CDCLK and PLL CDCLK as a source. All the entries in cdclk table for xe2lpd are defined with PLL CDCLK as source, so simply set it. Also skl_cdclk_decimal() shouldn't be set in CDCLK_CTL anymore, so skip it for display version 20 and above. v2: - Remove unneeded comment and use REG_BIT() (Matt Roper) - Rename CDCLK_SOURCE_SEL_CDCLK_PLL() to MDCLK_SOURCE_SEL_CDCLK_PLL to match spec (Lucas) Signed-off-by:Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-22-lucas.demarchi@intel.com
-
Matt Roper authored
Xe2_LPD supports DC5, DC6, and DC9 (DC3CO no longer exists). The overall programming and requirements to enter DC states are similar to those of Xe_LPD+ although AUX transactions do not require DC5/DC6 exit as they did previously. Bspec: 68851, 68857, 68886, 69115 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-21-lucas.demarchi@intel.com
-
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:
-
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: -
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:
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:
-
