Patch "drm/i915: Update vblank timestamping stuff on seamless M/N change" has been added to the 6.2-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    drm/i915: Update vblank timestamping stuff on seamless M/N change

to the 6.2-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     drm-i915-update-vblank-timestamping-stuff-on-seamles.patch
and it can be found in the queue-6.2 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit fb77a1cc43813aa6d1bf3cfc4138057d05abff0e
Author: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
Date:   Sat Mar 11 01:58:25 2023 +0200

    drm/i915: Update vblank timestamping stuff on seamless M/N change
    
    [ Upstream commit 59ad01c786a4c94afacc7feb0ab97bf8d6672a46 ]
    
    When we change the M/N values seamlessly during a fastset we should
    also update the vblank timestamping stuff to make sure the vblank
    timestamp corrections/guesstimations come out exact.
    
    Note that only crtc_clock and framedur_ns can actually end up
    changing here during fastsets. Everything else we touch can
    only change during full modesets.
    
    Technically we should try to do this exactly at the start of
    vblank, but that would require some kind of double buffering
    scheme. Let's skip that for now and just update things right
    after the commit has been submitted to the hardware. This
    means the information will be properly up to date when the
    vblank irq handler goes to work. Only if someone ends up
    querying some vblanky stuff in between the commit and start
    of vblank may we see a slight discrepancy.
    
    Also this same problem really exists for the DRRS downclocking
    stuff. But as that is supposed to be more or less transparent
    to the user, and it only drops to low gear after a long delay
    (1 sec currently) we probably don't have to worry about it.
    Any time something is actively submitting updates DRRS will
    remain in high gear and so the timestamping constants will
    match the hardware state.
    
    Reviewed-by: Jani Nikula <jani.nikula@xxxxxxxxx>
    Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@xxxxxxxxx>
    Fixes: e6f29923c048 ("drm/i915: Allow M/N change during fastset on bdw+")
    Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230310235828.17439-1-ville.syrjala@xxxxxxxxxxxxxxx
    (cherry picked from commit 8cb1f95cca68421b08333175719fdd3615372ca8)
    Signed-off-by: Jani Nikula <jani.nikula@xxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c b/drivers/gpu/drm/i915/display/intel_crtc.c
index 037fc140b585c..098acef59c10f 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -682,6 +682,14 @@ void intel_pipe_update_end(struct intel_crtc_state *new_crtc_state)
 	 */
 	intel_vrr_send_push(new_crtc_state);
 
+	/*
+	 * Seamless M/N update may need to update frame timings.
+	 *
+	 * FIXME Should be synchronized with the start of vblank somehow...
+	 */
+	if (new_crtc_state->seamless_m_n && intel_crtc_needs_fastset(new_crtc_state))
+		intel_crtc_update_active_timings(new_crtc_state);
+
 	local_irq_enable();
 
 	if (intel_vgpu_active(dev_priv))



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux