From: Jani Nikula <jani.nikula@linux.intel.com>
To: Ville Syrjala <ville.syrjala@linux.intel.com>,
intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 4/4] drm/i915: Extract intel_crtc_scanline_offset()
Date: Tue, 07 Mar 2023 14:29:50 +0200 [thread overview]
Message-ID: <874jqwsq0x.fsf@intel.com> (raw)
In-Reply-To: <20230306152841.6563-4-ville.syrjala@linux.intel.com>
On Mon, 06 Mar 2023, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Pull the scanline_offset calculation into its own function. Might
> have further use for this later with DSB scanline waits.
>
> 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 | 89 +++++++++++----------
> 1 file changed, 48 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_vblank.c b/drivers/gpu/drm/i915/display/intel_vblank.c
> index 48bf3923af11..f8bf9810527d 100644
> --- a/drivers/gpu/drm/i915/display/intel_vblank.c
> +++ b/drivers/gpu/drm/i915/display/intel_vblank.c
> @@ -441,6 +441,53 @@ 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);
> + const struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode;
> +
> + /*
> + * 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 (or rather add vtotal-1
> + * to keep the value positive), instead of adding 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) {
> + int vtotal;
> +
> + vtotal = adjusted_mode->crtc_vtotal;
> + if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
> + vtotal /= 2;
> +
> + return vtotal - 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)
> {
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> @@ -479,47 +526,7 @@ void intel_crtc_update_active_timings(const struct intel_crtc_state *crtc_state)
>
> crtc->mode_flags = crtc_state->mode_flags;
>
> - /*
> - * 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 (or rather add vtotal-1
> - * to keep the value positive), instead of adding 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) {
> - int vtotal;
> -
> - vtotal = adjusted_mode.crtc_vtotal;
> - if (adjusted_mode.flags & DRM_MODE_FLAG_INTERLACE)
> - vtotal /= 2;
> -
> - crtc->scanline_offset = vtotal - 1;
> - } else if (HAS_DDI(i915) &&
> - intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
> - crtc->scanline_offset = 2;
> - } else {
> - crtc->scanline_offset = 1;
> - }
> + crtc->scanline_offset = intel_crtc_scanline_offset(crtc_state);
>
> spin_unlock(&i915->uncore.lock);
> spin_unlock_irqrestore(&i915->drm.vblank_time_lock, irqflags);
--
Jani Nikula, Intel Open Source Graphics Center
next prev parent reply other threads:[~2023-03-07 12:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-06 15:28 [Intel-gfx] [PATCH 1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change Ville Syrjala
2023-03-06 15:28 ` [Intel-gfx] [PATCH 2/4] drm/i915: Add belts and suspenders locking for seamless M/N changes Ville Syrjala
2023-03-07 12:24 ` Jani Nikula
2023-03-07 14:13 ` Ville Syrjälä
2023-03-07 14:23 ` Jani Nikula
2023-03-06 15:28 ` [Intel-gfx] [PATCH 3/4] drm/i915: Relocate intel_crtc_update_active_timings() Ville Syrjala
2023-03-07 12:28 ` Jani Nikula
2023-03-10 19:41 ` Golani, Mitulkumar Ajitkumar
2023-03-06 15:28 ` [Intel-gfx] [PATCH 4/4] drm/i915: Extract intel_crtc_scanline_offset() Ville Syrjala
2023-03-07 12:29 ` Jani Nikula [this message]
2023-03-10 19:42 ` Golani, Mitulkumar Ajitkumar
2023-03-07 12:16 ` [Intel-gfx] [PATCH 1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change Jani Nikula
2023-03-07 14:13 ` Ville Syrjälä
2023-03-10 19:01 ` Golani, Mitulkumar Ajitkumar
2023-03-10 20:46 ` Ville Syrjälä
2023-03-10 23:45 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change (rev4) Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874jqwsq0x.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ville.syrjala@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.