summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/display
AgeCommit message (Collapse)Author
2025-04-04drm/i915: Drop force_check_qgvVille Syrjälä
Remove the force_check_qgv flag and just fill the pipe_sagv_reject bitmask properly during readout. This will cause the initial commit to re-enable SAGV if possible. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-04-04drm/i915: Flag even inactive crtcs as "inherited"Ville Syrjälä
I want to use the crtc_state->inherited flag to clean up some of the early SAGV handling. To make that work nicely I need to flag even the inactive crtcs as "inherited". Since we can't expect user space to perform any real commits on inactive crtcs we'll clear the flag already during initial_commit(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-04-04drm/i915: Do more bw readoutVille Syrjälä
Update a bunch of bw related stuff during readout: - bw_state->dbuf_bw possible now that the wm readout has given us access to the plane ddb data - cdclk_state->bw_min_cdclk Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-04-04drm/i915: Avoid triggering unwanted cdclk changes due to dbuf bandwidth changesVille Syrjälä
Currently intel_bw_calc_min_cdclk() always adds the bw_state to the atomic state. Not only does it result in potentially redundant work later, it's also currently causing unwanted cdclk changes during driver load. Check if the dbuf bw is actually changing before we decide to pull in the bw state. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-04-04drm/i915: Pass intel_dbuf_bw to skl_*_calc_dbuf_bw() explicitlyVille Syrjälä
Make skl_*_calc_dbuf_bw() a bit lower level passing in the to be mutated dbuf_bw struct in explicitly. This will allow more reuse later. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-04-04drm/i915: Extract intel_dbuf_bw_changed()Ville Syrjälä
Extract the struct intel_dbuf_bw comparison into a small helper. We'll get more users later. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-04-04drm/i915: s/intel_crtc_bw/intel_dbuf_bw/Ville Syrjälä
Rename the intel_crtc_bw struct to intel_dbuf_bw to better reflect what it does. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-04-04drm/i915: Drop the cached per-pipe min_cdclk[] from bw stateVille Syrjälä
intel_bw_crtc_min_cdclk() only depends on the pipe data rate, which we already have stashed in bw_state->data_rate[]. So stashing the resulting min_cdclk[] as well is redundant. Get rid of it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-04-02drm/i915/dp: Reject HBR3 when sink doesn't support TPS4Ville Syrjälä
According to the DP spec TPS4 is mandatory for HBR3. We have however seen some broken eDP sinks that violate this and declare support for HBR3 without TPS4 support. At least in the case of the icl Dell XPS 13 7390 this results in an unstable output. Reject HBR3 when TPS4 supports is unavailable on the sink. v2: Leave breadcrumbs in dmesg to avoid head scratching (Jani) Cc: stable@vger.kernel.org Cc: Jani Nikula <jani.nikula@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250306210740.11886-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-04-02drm/i915/psr: Prevent DP Panel Replay as well when CRC is enableJouni Högander
We are seeing timeouts in opening CRC fd when testing on setup where DP Panel Replay can be enabled. Fix these by checking if CRC is enabled for DP Panel Replay as well. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20250331090747.2964028-1-jouni.hogander@intel.com
2025-04-02drm/i915: Eliminate the initial_plane_phys_{smem,lmem}() duplicationVille Syrjälä
initial_plane_phys_lmem() and initial_plane_phys_smem() are now identical. Remove one of them. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250313140838.29742-11-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-04-02drm/i915: Use intel_memory_region_type_is_local() in the BIOS FB takeoverVille Syrjälä
Replace the hardcoded PTE vs. memory region is_local checks in the BIOS FB takeover with intel_memory_region_type_is_local(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250313140838.29742-10-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-04-02drm/i915: Lookup the memory region first in the BIOS FB takeoverVille Syrjälä
When doing the BIOS FB takeover let's look up the appropriate memory region first. If it doesn't exist there's not much point in doing the PTE read/etc either. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250313140838.29742-9-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-04-02drm/i915: Use a nicer way to lookup the memory region in BIOS FB takeoverVille Syrjälä
Use intel_memory_region_by_type() to find the appropriate memory region for the BIOS FB takeover. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250313140838.29742-8-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-04-02drm/i915: Verify the BIOS FB first PTE on non-LMEMBAR systemsVille Syrjälä
Now that we have intel_ggtt_read_entry() we can easily read out the first PTE of the BIOS FB and verify that it looks correct. We'll also use the extracted dma address to figure out where in stolen the FB lives (so far we've just assumed that it sits at offset 0, and in practice that does seem to be true, but better safe than sorry). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250313140838.29742-7-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-04-02drm/i915: Use intel_ggtt_read_entry() in the BIOS FB takeoverVille Syrjälä
Use intel_ggtt_read_entry() instead of open coding the PTE read/decode in the BIOS FB takeover code. So far this codepath only covers platforms with LMEMBAR. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250313140838.29742-6-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-04-01drm/i915: reduce intel_wakeref.h dependenciesJani Nikula
Forward declare struct drm_printer instead of including drm/drm_print.h, as we only need the pointer. Turns out quite a few places depend on this include implicitly. Make them explicit. Some of the includes are just stale and unnecessary. Group the forward declarations together while at it. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250326115452.2090275-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-03-31drm/i915/display: Fix htmldocs buildRodrigo Vivi
Fixes a wrong documentation block indentation: Documentation/gpu/i915:141: ./drivers/gpu/drm/i915/display/intel_hotplug.c:1080: ERROR: Unexpected indentation. Documentation/gpu/i915:141: ./drivers/gpu/drm/i915/display/intel_hotplug.c:1082: WARNING: Block quote ends without a blank line; unexpected unindent. v2: Use an empty line instead of changing block indentation (Imre) Fixes: 0d77a3e0ea90 ("drm/i915/hpd: Add support for blocking the IRQ handling on an HPD pin") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/intel-gfx/20250312232506.47451f83@canb.auug.org.au/ Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250328180829.25892-1-rodrigo.vivi@intel.com Link: https://lore.kernel.org/r/20250328193202.40884-1-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-03-31drm/i915/display: implement wa_18038517565Vinod Govindapillai
Disable FBC compressor clock gating before enabling FBC and clear it after disabling FBC. v2: update the DG2 registers for this wa v3: use local variable and single line reg definition (Jani) Bspec: 74212, 72197, 69741, 65555 Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20250330172616.718188-1-vinod.govindapillai@intel.com
2025-03-31drm/i915/psr: Add PSR pause/resume reference countJouni Högander
We have now seen this: <4> [2120.434153] i915 0000:00:02.0: [drm] drm_WARN_ON(psr->paused) <4> [2120.434196] WARNING: CPU: 3 PID: 4430 at drivers/gpu/drm/i915/display/intel_psr.c:2227 intel_psr_pause+0x16e/0x180 [i915] Comment for drm_WARN_ON(display->drm, psr->paused) in intel_psr_pause says: "If we ever hit this, we will need to add refcount to pause/resume" This patch is implementing PSR pause/resume refcount. v3: Incorporate changes missing from v2 v2: Add drm_warn for detecting possible unbalanced pause/resume Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://lore.kernel.org/r/20250328080623.1183669-1-jouni.hogander@intel.com
2025-03-31drm/i915/display: Avoid use of VTOTAL.Vtotal bitsAnkit Nautiyal
For platforms that always use VRR Timing Generator, the VTOTAL.Vtotal bits are not required. Since the support for these bits is going to be deprecated in upcoming platforms, avoid writing these bits for the platforms that do not use legacy Timing Generator. Since for these platforms vrr.vmin is always filled with crtc_vtotal, use TRAN_VRR_VMIN to get the vtotal for adjusted_mode. v2: Avoid having a helper for manipulating VTOTAL register, and instead just make the change where required. (Ville) v3: Set crtc_vtotal instead of working with the bits directly (Ville). Use intel_vrr_vmin_vtotal() to set the vtotal during readout. (Ville) v4: Keep the reading part unchanged, and let it get overwritten for cases where we use vrr.vmin. (Ville) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250327144629.648306-3-ankit.k.nautiyal@intel.com
2025-03-31drm/i915/display: Introduce transcoder_has_vrr() helperAnkit Nautiyal
Introduce a new helper to check transcoder_has_vrr() and use that to exclude transcoders which do not support VRR. v2: Include HAS_VRR into the helper. (Ville) v3: Drop the usage in places where not applicable. (Ville) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250327144629.648306-2-ankit.k.nautiyal@intel.com
2025-03-28drm/i915/display: drop some unnecessary intel_de_* compatibility wrappersJani Nikula
intel_de_wait_for_set(), intel_de_wait_for_clear(), intel_de_read_fw(), and intel_de_write_fw() are only passed struct intel_display. Remove the unnecessary compatibility wrappers. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/35589d84ee7996f8972ddb3ebc1aae1b53077b19.1742906146.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-03-28drm/i915/wa: convert intel_display_wa.[ch] to struct intel_displayJani Nikula
Going forward, struct intel_display is the main display device data pointer. Convert as much as possible of intel_display_wa.[ch] to struct intel_display. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/821937f9fcdcb7d5516be0c48c2cee009936ecb8.1742906146.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-03-28drm/i915/psr: further conversions to struct intel_displayJani Nikula
intel_psr.c still uses the old platform identification macros. Convert them and some other stragglers to struct intel_display. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/7d032bd621a56536b4d53c5c415cad624e5dc628.1742906146.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-03-28drm/i915/crc: convert intel_pipe_crc.c to struct intel_displayJani Nikula
Going forward, struct intel_display is the main display device data pointer. Convert as much as possible of intel_pipe_crc.c to struct intel_display. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/9bb18395d57d5353535e0d385119366821162a86.1742906146.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-03-28drm/i915/ddi: convert intel_ddi.c to struct intel_displayJani Nikula
Going forward, struct intel_display is the main display device data pointer. Convert as much as possible of intel_ddi.c to struct intel_display. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/44aebcf93b2211e917b2ee725433b1f9b5e4e6f6.1742906146.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-03-28drm/i915/dpll: convert intel_dpll.[ch] to struct intel_displayJani Nikula
Going forward, struct intel_display is the main display device data pointer. Convert as much as possible of intel_dpll.[ch] to struct intel_display. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/16fe331ba51c269d6f9871d7b0a3b8df3c7b5342.1742906146.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-03-27drm/i915/dsi: let HW maintain the HS-TRAIL timingWilliam Tseng
This change is to avoid over-specification of the TEOT timing parameter, which is derived from software in current design. Supposed that THS-TRAIL and THS-EXIT have the minimum values, i.e., 60 and 100 in ns. If SW is overriding the HW default, the TEOT value becomes 150 ns, approximately calculated by the following formula. DIV_ROUND_UP(60/50)*50 + DIV_ROUND_UP(100/50))*50/2, where 50 is LP Escape Clock time in ns. The TEOT value 150 ns is larger than the maximum value, around 136 ns if UI is 1.8ns, (105 ns + 12*UI, defined by MIPI DPHY specification). However, the TEOT value will meet the specification if THS-TRAIL is set to the HW default, instead of software overriding. The timing change is made for both data lane and clock lane. v1: initial version. v2: change clock lane dphy timings. v3: remove calculation of trail cnt. v4: rebase. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13891 Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Lee Shawn C <shawn.c.lee@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Signed-off-by: William Tseng <william.tseng@intel.com> Acked-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Link: https://lore.kernel.org/r/20250311100626.533888-1-william.tseng@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-03-25drm/i915: Move intel_disable_shared_dpll() into ilk_pch_post_disable()Ville Syrjälä
On ILK-IVB only PCH outputs use shared dplls. Move the relevant intel_disable_shared_dpll() into ilk_pch_post_disable() to make that clear (and if we extend the dpll mgr to cover all plls we need different enable/disable points anyway for the PCH vs. CPU eDP cases). The intel_enable_shared_dpll() counterpart was already in ilk_pch_enable() anyway, so this is the more symmetric place for the disable as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250310183528.3203-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-03-25drm/i915: Enable/disable shared dplls just the once for joined pipesVille Syrjälä
Currently we loop over all joined pipes and enable/disable the shared dplls for each. We don't really have to do that since all joined pipes will be using the same dpll. So let's just do the enable/disable once for the whole set of joined pipes. We can still keep tracking the dpll active set as pipes as long as we remember to flip the bits for all the joined pipes on one go. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250310183528.3203-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-03-25drm/i915/vrr: Set trans_vrr_ctl in intel_vrr_set_transcoder_timings()Ankit Nautiyal
We now always set vrr.flipline, vmin, and vmax for all platforms that support VRR. Therefore, we should set all TRANS_VRR_CTL bits except VRR_ENABLE. Without this, the readback for these bits will fail because we only read vrr.flipline, vmin, and vmax if TRANS_VRR_CTL has the FLIPLINE_EN bit set. For platforms that always have the VRR Timing Generator enabled, the FLIPLINE_EN bit is always set in TRANS_VRR_CTL during intel_transcoder_vrr_enable(). However, for the remaining platforms (that do not always have the VRR Timing Generator enabled) if a full modeset doesn't occur and VRR is not enabled, the bit is not set. This results in a mismatch between the software state and hardware state because the software state expects VRR timings like flipline, vmin, and vmax to be set, but the readout for these doesn't happen since the FLIPLINE_EN bit is not set in TRANS_VRR_CTL. To avoid this mismatch, write trans_vrr_ctl in intel_vrr_set_transcoder_timings() even when VRR is not enabled for platforms that do not have the VRR Timing Generator always enabled. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250324133248.4071909-15-ankit.k.nautiyal@intel.com
2025-03-25drm/i915/vrr: Always use VRR timing generator for PTL+Ankit Nautiyal
Currently, the VRR timing generator is used only when VRR is enabled by userspace for sinks that support VRR. Starting with PTL+, gradually move away from the legacy timing generator and use the VRR timing generator for both variable and fixed timings. Note: For platforms where we always enable the VRR timing generator, the LRR fastset is not allowed to avoid live programming of vrr.guardband with VRR TG enabled. This effectively breaks the LRR fastset functionality for these platforms and needs to be addressed. v2: Use this for PTL for now to avoid losing LRR fastset for older platforms. (Ville) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250324133248.4071909-14-ankit.k.nautiyal@intel.com
2025-03-25drm/i915/vrr: Allow fixed_rr with pipe joinerAnkit Nautiyal
VRR with joiner is currently disabled as it still needs some work to correctly sequence the primary and secondary transcoders. However, we can still use VRR Timing generator in fixed refresh rate for joiner and since it just need to program vrr timings once and does not involve changing timings on the fly. We still need to skip the VRR and LRR for joiner. To achieve this set vrr.in_range to 0 for joiner case, so that we do not try VRR and LRR for the joiner case. v2: Avoid checks for secondary pipes, where not required. (Ville) v3: Remove a redundant check and reset vrr.in_range to false. (Ville) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250324133248.4071909-13-ankit.k.nautiyal@intel.com
2025-03-25drm/i915/display: Move vrr.guardband/pipeline_full out of !fastset blockAnkit Nautiyal
Since the vrr.guardband can now change for platforms that always use the VRR Timing Generator, and it is unsafe to reprogram the guardband on the fly, move the guardband and pipeline_full checks from the pure !fastboot path and add a check for intel_vrr_always_use_vrr_tg(). For older platforms the vrr.guardband change happens when VRR Timing generator is off. For the platforms that always use the VRR Timing Generator, this will prevent reprogramming the vrr.guardband without a full modeset. However, this will disrupt LRR functionality for these platforms. v2: Modify the check to avoid breaking the LRR on older platform. (Ville) v3: Correct the oversight of not removing the lines from the original location. (Ville) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250324133248.4071909-12-ankit.k.nautiyal@intel.com
2025-03-25drm/i915/display: Use fixed rr timings in intel_set_transcoder_timings_lrr()Ankit Nautiyal
Update the intel_set_transcoder_timings_lrr() function to use fixed refresh rate timings. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250324133248.4071909-11-ankit.k.nautiyal@intel.com
2025-03-25drm/i915/vrr: Use fixed timings for platforms that support VRRAnkit Nautiyal
For fixed refresh rate use fixed timings for all platforms that support VRR. For this add checks to avoid computing and reading VRR for platforms that do not support VRR. v2: Avoid touching check for VRR_CTL_FLIP_LINE_EN. (Ville) v3: Avoid redundant statements in vrr_{compute/get}_config. (Ville) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250324133248.4071909-10-ankit.k.nautiyal@intel.com
2025-03-25drm/i915/display: Use fixed_rr timings in modeset sequenceAnkit Nautiyal
During modeset enable sequence, program the fixed timings, and turn on the VRR Timing Generator (VRR TG) for platforms that always use VRR TG. For this intel_vrr_set_transcoder now always programs fixed timings. Later if vrr timings are required, vrr_enable() will switch to the real VRR timings. For platforms that will always use VRR TG, the VRR_CTL Enable bit is set and reset in the transcoder enable/disable path. v2: Update intel_vrr_set_transcoder_timings for fixed_rr. v3: Update intel_set_transcoder_timings_lrr for fixed_rr. (Ville) v4: Have separate functions to enable/disable VRR CTL v5: -For platforms that do not always have VRRTG on, do write bits other than enable bit and also use write the TRANS_VRR_PUSH register. (Ville) -Avoid writing trans_ctl_vrr if !vrr_possible(). v6: -Disable VRR just before intel_ddi_disable_transcoder_func(). (Ville) -Correct the sequence of configuring PUSH and VRR Enable/Disable. (Ville) v7: Reset trans_vrr_ctl to 0 unconditionally in intel_vrr_transcoder_disable(). (Ville) v8: Reset trans_vrr_ctl if flipline is not set. (Ville) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250324133248.4071909-9-ankit.k.nautiyal@intel.com
2025-03-25drm/i915/vrr: Set vrr.enable for VRR TG with fixed_rrAnkit Nautiyal
For platforms that enable VRR TG only for variable timings, the VRR_CTL.VRR_ENABLE bit indicates VRR is active. For platforms that always have VRR TG enabled, the VRR_CTL.VRR_ENABLE bit indicates VRR is active only when not in fixed refresh rate mode. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250324133248.4071909-8-ankit.k.nautiyal@intel.com
2025-03-25drm/i915/vrr: Always set vrr vmax/vmin/flipline in vrr_{enable/disable}Ankit Nautiyal
For platforms for which vrr timing generator is always set, VRR_CTL enable bit does not need to toggle, so modify the vrr_{enable/disable} for this. At the moment the helper intel_vrr_always_use_vrr_tg() return false for all cases. This will be set later when all other bits are in place. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250324133248.4071909-7-ankit.k.nautiyal@intel.com
2025-03-25drm/i915/vrr: Refactor condition for computing vmax and LRRAnkit Nautiyal
LRR and Vmax can be computed only if VRR is supported and vrr.in_range is set. Currently we proceed with vrr timings only for VRR supporting panels and return otherwise. For using VRR TG with fix timings, need to continue even for panels that do not support VRR. To achieve this, refactor the condition for computing vmax and update_lrr so that we can continue for fixed timings for panels that do not support VRR. v2: Set vmax = vmin for non VRR panels. (Ville) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250324133248.4071909-6-ankit.k.nautiyal@intel.com
2025-03-25drm/i915/display: Move intel_psr_post_plane_update() at the laterAnkit Nautiyal
In intel_post_plane_update() there are things which might need to do vblank waits, so enabling PSR as early as we do now is simply counter-productive. Therefore move intel_psr_post_plane_update() at the last of intel_post_plane_update(). Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20250324133248.4071909-5-ankit.k.nautiyal@intel.com
2025-03-25drm/i915/display: Disable PSR before disabling VRRAnkit Nautiyal
As per bspec 49268: Disable PSR before disabling VRR. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250324133248.4071909-4-ankit.k.nautiyal@intel.com
2025-03-25drm/i915/dp_mst: Use VRR Timing generator for DP MST for fixed_rrAnkit Nautiyal
Currently the variable timings are supported only for DP and eDP and not for DP MST. Call intel_vrr_compute_config() for MST which will configure fixed refresh rate timings irrespective of whether VRR is supported or not. Since vrr_capable still doesn't have support for DP MST this will be just treated as non VRR case and vrr.vmin/vmax/flipline will be all set to adjusted_mode->crtc_vtotal. This will help to move away from the legacy timing generator and always use VRR timing generator by default. With this change, we need to exclude MST in intel_vrr_is_capable for now, to avoid having LRR with MST. v2: Exclude MST in intel_vrr_is_capable() for now. (Ville) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250324133248.4071909-3-ankit.k.nautiyal@intel.com
2025-03-25drm/i915/hdmi: Use VRR Timing generator for HDMI for fixed_rrAnkit Nautiyal
Currently VRR is not supported with HDMI, but we can still leverage the VRR Timing Generator to achieve a fixed refresh rate. Call intel_vrr_compute_config() for HDMI which will handle the vrr timings to have fixed refresh rate with VRR Timing Generator. v2: Improve commit message. (Ville). Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> (#v1) Link: https://lore.kernel.org/r/20250324133248.4071909-2-ankit.k.nautiyal@intel.com
2025-03-25drm/i915: Replace the HAS_DDI() in intel_crtc_scanline_offset() with ↵Ville Syrjälä
specific platform checks The HDMI vs. not scanline offset stuff no longer applies to the latest platforms, so using HAS_DDI() is a bit confusing. Replace with a more specific set of conditions. Also let's just deal with the platform types in the if ladder itself, and handle the HDMI vs. not within the specific branch for those platforms. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250207215406.19348-4-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-03-25drm/i915: Reverse the scanline_offset if ladderVille Syrjälä
Make intel_crtc_scanline_offset() a bit less confusing by fully reordering the if ladder to use the new->old platform order. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250207215406.19348-3-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-03-25drm/i915: Fix scanline_offset for LNL+ and BMG+Ville Syrjälä
Turns out LNL+ and BMG+ no longer have the weird extra scanline offset for HDMI outputs. Fix intel_crtc_scanline_offset() accordingly so that scanline evasion/etc. works correctly on HDMI outputs on these new platforms. Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250207215406.19348-2-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2025-03-25drm/i915/dp_mst: Fix side-band message timeouts due to long PPS delaysImre Deak
The Panel Power Sequencer lock held on an eDP port (a) blocks a DP AUX transfer on another port (b), since the PPS lock is device global, thus shared by all ports. The PPS lock can be held on port (a) for a longer period due to the various PPS delays (panel/backlight on/off, power-cycle delays). This in turn can cause an MST down-message request on port (b) time out, if the above PPS delay defers the handling of the reply to the request by more than 100ms: the MST branch device sending the reply (signaling this via the DP_DOWN_REP_MSG_RDY flag in the DP_DEVICE_SERVICE_IRQ_VECTOR DPCD register) may cancel the reply (clearing DP_DOWN_REP_MSG_RDY and the reply message buffer) after 110 ms, if the reply is not processed by that time. Avoid MST down-message timeouts described above, by locking the PPS state for AUX transfers only if this is actually required: on eDP ports, where the VDD power depends on the PPS state and on all DP and eDP ports on VLV/CHV, where the PPS is a pipe instance and hence a modeset on any port possibly affecting the PPS state. v2: Don't move PPS locking/VDD enabling to a separate function. (Jani) 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://lore.kernel.org/r/20250324180145.142884-3-imre.deak@intel.com
2025-03-25drm/i915/pps: Let calling intel_pps_vdd_{on, off}_unlocked() w/o PPS lock heldImre Deak
After a follow-up change on non-eDP outputs intel_pps_vdd_{on,off}_unlocked() can be called without the PPS lock held, allow for this. Suggested-by: 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://lore.kernel.org/r/20250324180145.142884-2-imre.deak@intel.com
generated by cgit (git 2.34.1) at 2025-07-18 11:21:16 +0000