Message ID | 20240528185647.7765-6-ville.syrjala@linux.intel.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | drm/i915: Cleanups around scanline arithmetic | expand |
On Tue, 28 May 2024, Ville Syrjala <ville.syrjala@linux.intel.com> wrote: > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > I want to use intel_crtc_scanline_offset() in > intel_crtc_scanline_to_hw(). Relocate intel_crtc_scanline_offset() > a bit to avoid a forward declaration. > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> > --- > drivers/gpu/drm/i915/display/intel_vblank.c | 76 ++++++++++----------- > 1 file changed, 38 insertions(+), 38 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_vblank.c b/drivers/gpu/drm/i915/display/intel_vblank.c > index b0e95a4c680d..eb80952b0cfd 100644 > --- a/drivers/gpu/drm/i915/display/intel_vblank.c > +++ b/drivers/gpu/drm/i915/display/intel_vblank.c > @@ -188,6 +188,44 @@ static u32 __intel_get_crtc_scanline_from_timestamp(struct intel_crtc *crtc) > return scanline; > } > > +static int intel_crtc_scanline_offset(const struct intel_crtc_state *crtc_state) > +{ > + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev); > + > + /* > + * The scanline counter increments at the leading edge of hsync. > + * > + * On most platforms it starts counting from vtotal-1 on the > + * first active line. That means the scanline counter value is > + * always one less than what we would expect. Ie. just after > + * start of vblank, which also occurs at start of hsync (on the > + * last active line), the scanline counter will read vblank_start-1. > + * > + * On gen2 the scanline counter starts counting from 1 instead > + * of vtotal-1, so we have to subtract one. > + * > + * On HSW+ the behaviour of the scanline counter depends on the output > + * type. For DP ports it behaves like most other platforms, but on HDMI > + * there's an extra 1 line difference. So we need to add two instead of > + * one to the value. > + * > + * On VLV/CHV DSI the scanline counter would appear to increment > + * approx. 1/3 of a scanline before start of vblank. Unfortunately > + * that means we can't tell whether we're in vblank or not while > + * we're on that particular line. We must still set scanline_offset > + * to 1 so that the vblank timestamps come out correct when we query > + * the scanline counter from within the vblank interrupt handler. > + * However if queried just before the start of vblank we'll get an > + * answer that's slightly in the future. > + */ > + if (DISPLAY_VER(i915) == 2) > + return -1; > + else if (HAS_DDI(i915) && intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) > + return 2; > + else > + return 1; > +} > + > /* > * intel_de_read_fw(), only for fast reads of display block, no need for > * forcewake etc. > @@ -467,44 +505,6 @@ void intel_wait_for_pipe_scanline_moving(struct intel_crtc *crtc) > wait_for_pipe_scanline_moving(crtc, true); > } > > -static int intel_crtc_scanline_offset(const struct intel_crtc_state *crtc_state) > -{ > - struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev); > - > - /* > - * The scanline counter increments at the leading edge of hsync. > - * > - * On most platforms it starts counting from vtotal-1 on the > - * first active line. That means the scanline counter value is > - * always one less than what we would expect. Ie. just after > - * start of vblank, which also occurs at start of hsync (on the > - * last active line), the scanline counter will read vblank_start-1. > - * > - * On gen2 the scanline counter starts counting from 1 instead > - * of vtotal-1, so we have to subtract one. > - * > - * On HSW+ the behaviour of the scanline counter depends on the output > - * type. For DP ports it behaves like most other platforms, but on HDMI > - * there's an extra 1 line difference. So we need to add two instead of > - * one to the value. > - * > - * On VLV/CHV DSI the scanline counter would appear to increment > - * approx. 1/3 of a scanline before start of vblank. Unfortunately > - * that means we can't tell whether we're in vblank or not while > - * we're on that particular line. We must still set scanline_offset > - * to 1 so that the vblank timestamps come out correct when we query > - * the scanline counter from within the vblank interrupt handler. > - * However if queried just before the start of vblank we'll get an > - * answer that's slightly in the future. > - */ > - if (DISPLAY_VER(i915) == 2) > - return -1; > - else if (HAS_DDI(i915) && intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) > - return 2; > - else > - return 1; > -} > - > void intel_crtc_update_active_timings(const struct intel_crtc_state *crtc_state, > bool vrr_enable) > {
diff --git a/drivers/gpu/drm/i915/display/intel_vblank.c b/drivers/gpu/drm/i915/display/intel_vblank.c index b0e95a4c680d..eb80952b0cfd 100644 --- a/drivers/gpu/drm/i915/display/intel_vblank.c +++ b/drivers/gpu/drm/i915/display/intel_vblank.c @@ -188,6 +188,44 @@ static u32 __intel_get_crtc_scanline_from_timestamp(struct intel_crtc *crtc) return scanline; } +static int intel_crtc_scanline_offset(const struct intel_crtc_state *crtc_state) +{ + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev); + + /* + * The scanline counter increments at the leading edge of hsync. + * + * On most platforms it starts counting from vtotal-1 on the + * first active line. That means the scanline counter value is + * always one less than what we would expect. Ie. just after + * start of vblank, which also occurs at start of hsync (on the + * last active line), the scanline counter will read vblank_start-1. + * + * On gen2 the scanline counter starts counting from 1 instead + * of vtotal-1, so we have to subtract one. + * + * On HSW+ the behaviour of the scanline counter depends on the output + * type. For DP ports it behaves like most other platforms, but on HDMI + * there's an extra 1 line difference. So we need to add two instead of + * one to the value. + * + * On VLV/CHV DSI the scanline counter would appear to increment + * approx. 1/3 of a scanline before start of vblank. Unfortunately + * that means we can't tell whether we're in vblank or not while + * we're on that particular line. We must still set scanline_offset + * to 1 so that the vblank timestamps come out correct when we query + * the scanline counter from within the vblank interrupt handler. + * However if queried just before the start of vblank we'll get an + * answer that's slightly in the future. + */ + if (DISPLAY_VER(i915) == 2) + return -1; + else if (HAS_DDI(i915) && intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) + return 2; + else + return 1; +} + /* * intel_de_read_fw(), only for fast reads of display block, no need for * forcewake etc. @@ -467,44 +505,6 @@ void intel_wait_for_pipe_scanline_moving(struct intel_crtc *crtc) wait_for_pipe_scanline_moving(crtc, true); } -static int intel_crtc_scanline_offset(const struct intel_crtc_state *crtc_state) -{ - struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev); - - /* - * The scanline counter increments at the leading edge of hsync. - * - * On most platforms it starts counting from vtotal-1 on the - * first active line. That means the scanline counter value is - * always one less than what we would expect. Ie. just after - * start of vblank, which also occurs at start of hsync (on the - * last active line), the scanline counter will read vblank_start-1. - * - * On gen2 the scanline counter starts counting from 1 instead - * of vtotal-1, so we have to subtract one. - * - * On HSW+ the behaviour of the scanline counter depends on the output - * type. For DP ports it behaves like most other platforms, but on HDMI - * there's an extra 1 line difference. So we need to add two instead of - * one to the value. - * - * On VLV/CHV DSI the scanline counter would appear to increment - * approx. 1/3 of a scanline before start of vblank. Unfortunately - * that means we can't tell whether we're in vblank or not while - * we're on that particular line. We must still set scanline_offset - * to 1 so that the vblank timestamps come out correct when we query - * the scanline counter from within the vblank interrupt handler. - * However if queried just before the start of vblank we'll get an - * answer that's slightly in the future. - */ - if (DISPLAY_VER(i915) == 2) - return -1; - else if (HAS_DDI(i915) && intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) - return 2; - else - return 1; -} - void intel_crtc_update_active_timings(const struct intel_crtc_state *crtc_state, bool vrr_enable) {