[Intel-gfx] [PATCH 2/4] drm/i915: Add belts and suspenders locking for seamless M/N changes
Jani Nikula
jani.nikula at linux.intel.com
Tue Mar 7 14:23:01 UTC 2023
On Tue, 07 Mar 2023, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
> On Tue, Mar 07, 2023 at 02:24:08PM +0200, Jani Nikula wrote:
>> On Mon, 06 Mar 2023, Ville Syrjala <ville.syrjala at linux.intel.com> wrote:
>> > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
>> >
>> > Add some (probably overkill) locking to protect the vblank
>> > timestamping constants updates during seamless M/N fastsets.
>> >
>> > As everything should be naturally aligned I think the individual
>> > pieces should probably end up updating atomically enough. So this
>> > is only really meant to guarantee everyone sees a consistent whole.
>> >
>> > All the drm_vblank.c usage is covered by vblank_time_lock,
>> > and uncore.lock will take care of __intel_get_crtc_scanline()
>> > that can also be called from outside the core vblank functionality.
>>
>> The patch seems to do what it says on the box, but I increasingly
>> dislike the use of uncore.lock for anything other than the nuts and
>> bolts of uncore.
>
> Yeah, it's not really great. Hence the TODO I left behind there.
Okay,
Reviewed-by: Jani Nikula <jani.nikula at intel.com>
>
>>
>> BR,
>> Jani.
>>
>> >
>> > Currently only crtc_clock and framedur_ns can change, but in
>> > the future might fastset also across eg. vtotal/vblank_end
>> > changes, so let's just grab the locks across the whole thing.
>> >
>> > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
>> > ---
>> > drivers/gpu/drm/i915/display/intel_display.c | 24 +++++++++++++++++++-
>> > 1 file changed, 23 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
>> > index a1fbdf32bd21..020320468967 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_display.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> > @@ -5908,6 +5908,8 @@ void intel_crtc_update_active_timings(const struct intel_crtc_state *crtc_state)
>> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> > struct drm_display_mode adjusted_mode;
>> > + int vmax_vblank_start = 0;
>> > + unsigned long irqflags;
>> >
>> > drm_mode_init(&adjusted_mode, &crtc_state->hw.adjusted_mode);
>> >
>> > @@ -5915,11 +5917,28 @@ void intel_crtc_update_active_timings(const struct intel_crtc_state *crtc_state)
>> > adjusted_mode.crtc_vtotal = crtc_state->vrr.vmax;
>> > adjusted_mode.crtc_vblank_end = crtc_state->vrr.vmax;
>> > adjusted_mode.crtc_vblank_start = intel_vrr_vmin_vblank_start(crtc_state);
>> > - crtc->vmax_vblank_start = intel_vrr_vmax_vblank_start(crtc_state);
>> > + vmax_vblank_start = intel_vrr_vmax_vblank_start(crtc_state);
>> > }
>> >
>> > + /*
>> > + * Belts and suspenders locking to guarantee everyone sees 100%
>> > + * consistent state during fastset seamless refresh rate changes.
>> > + *
>> > + * vblank_time_lock takes care of all drm_vblank.c stuff, and
>> > + * uncore.lock takes care of __intel_get_crtc_scanline() which
>> > + * may get called elsewhere as well.
>> > + *
>> > + * TODO maybe just protect everything (including
>> > + * __intel_get_crtc_scanline()) with vblank_time_lock?
>> > + * Need to audit everything to make sure it's safe.
>> > + */
>> > + spin_lock_irqsave(&dev_priv->drm.vblank_time_lock, irqflags);
>> > + spin_lock(&dev_priv->uncore.lock);
>> > +
>> > drm_calc_timestamping_constants(&crtc->base, &adjusted_mode);
>> >
>> > + crtc->vmax_vblank_start = vmax_vblank_start;
>> > +
>> > crtc->mode_flags = crtc_state->mode_flags;
>> >
>> > /*
>> > @@ -5963,6 +5982,9 @@ void intel_crtc_update_active_timings(const struct intel_crtc_state *crtc_state)
>> > } else {
>> > crtc->scanline_offset = 1;
>> > }
>> > +
>> > + spin_unlock(&dev_priv->uncore.lock);
>> > + spin_unlock_irqrestore(&dev_priv->drm.vblank_time_lock, irqflags);
>> > }
>> >
>> > /*
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center
--
Jani Nikula, Intel Open Source Graphics Center
More information about the Intel-gfx
mailing list