From 3eb08ea58e5717cf758b9eff6d9604aa3525ab94 Mon Sep 17 00:00:00 2001 From: Ville Syrjälä Date: Tue, 14 Feb 2023 00:52:50 +0200 Subject: drm/i915: s/PIPECONF/TRANSCONF/ MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Rename PIPECONF to TRANSCONF to make it clear what it actually applies to. While the usual convention is to pick the earliers name I think in this case it's more clear to use the later name. Especially as even the register offset is in the wrong range (0x70000 vs. 0x60000) and thus makes it look like this is per-pipe. There is one place in gvt that's doing something with TRANSCONF while iterating with for_each_pipe(). So that might not be doing the right thing for TRANSCODER_EDP, dunno. Not knowing what it does I left it as is to avoid breakage. Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20230213225258.2127-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_vblank.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'drivers/gpu/drm/i915/display/intel_vblank.c') diff --git a/drivers/gpu/drm/i915/display/intel_vblank.c b/drivers/gpu/drm/i915/display/intel_vblank.c index 4c83e2320bca..571f5dda1e66 100644 --- a/drivers/gpu/drm/i915/display/intel_vblank.c +++ b/drivers/gpu/drm/i915/display/intel_vblank.c @@ -26,7 +26,7 @@ * | * | frame start: * | generate frame start interrupt (aka. vblank interrupt) (gmch) - * | may be shifted forward 1-3 extra lines via PIPECONF + * | may be shifted forward 1-3 extra lines via TRANSCONF * | | * | | start of vsync: * | | generate vsync interrupt @@ -54,7 +54,7 @@ * Summary: * - most events happen at the start of horizontal sync * - frame start happens at the start of horizontal blank, 1-4 lines - * (depending on PIPECONF settings) after the start of vblank + * (depending on TRANSCONF settings) after the start of vblank * - gen3/4 pixel and frame counter are synchronized with the start * of horizontal active on the first line of vertical active */ -- cgit From 84f4ebe8c1abbe375babbea46eab746a0060e80c Mon Sep 17 00:00:00 2001 From: Ville Syrjälä Date: Sat, 11 Mar 2023 01:58:27 +0200 Subject: drm/i915: Relocate intel_crtc_update_active_timings() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Move intel_crtc_update_active_timings() into intel_vblank.c where it more properly belongs. Also do the s/dev_priv/i915/ modernization rename while at it. Reviewed-by: Jani Nikula Reviewed-by: Mitul Golani Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20230310235828.17439-3-ville.syrjala@linux.intel.com --- drivers/gpu/drm/i915/display/intel_vblank.c | 85 +++++++++++++++++++++++++++++ 1 file changed, 85 insertions(+) (limited to 'drivers/gpu/drm/i915/display/intel_vblank.c') diff --git a/drivers/gpu/drm/i915/display/intel_vblank.c b/drivers/gpu/drm/i915/display/intel_vblank.c index 571f5dda1e66..48bf3923af11 100644 --- a/drivers/gpu/drm/i915/display/intel_vblank.c +++ b/drivers/gpu/drm/i915/display/intel_vblank.c @@ -8,6 +8,7 @@ #include "intel_de.h" #include "intel_display_types.h" #include "intel_vblank.h" +#include "intel_vrr.h" /* * This timing diagram depicts the video signal in and @@ -439,3 +440,87 @@ void intel_wait_for_pipe_scanline_moving(struct intel_crtc *crtc) { wait_for_pipe_scanline_moving(crtc, true); } + +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 *i915 = 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); + + if (crtc_state->vrr.enable) { + 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); + 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(&i915->drm.vblank_time_lock, irqflags); + spin_lock(&i915->uncore.lock); + + drm_calc_timestamping_constants(&crtc->base, &adjusted_mode); + + crtc->vmax_vblank_start = vmax_vblank_start; + + 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; + } + + spin_unlock(&i915->uncore.lock); + spin_unlock_irqrestore(&i915->drm.vblank_time_lock, irqflags); +} -- cgit From b5202a93cd3768b5f757dbc1c7d702772a34c9a3 Mon Sep 17 00:00:00 2001 From: Ville Syrjälä Date: Sat, 11 Mar 2023 01:58:28 +0200 Subject: drm/i915: Extract intel_crtc_scanline_offset() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Pull the scanline_offset calculation into its own function. Might have further use for this later with DSB scanline waits. Reviewed-by: Jani Nikula Reviewed-by: Mitul Golani Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20230310235828.17439-4-ville.syrjala@linux.intel.com --- drivers/gpu/drm/i915/display/intel_vblank.c | 89 ++++++++++++++++------------- 1 file changed, 48 insertions(+), 41 deletions(-) (limited to 'drivers/gpu/drm/i915/display/intel_vblank.c') 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); -- cgit