From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 057FDC63705 for ; Wed, 7 Dec 2022 21:05:20 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B912310E420; Wed, 7 Dec 2022 21:05:18 +0000 (UTC) Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id C091910E41F for ; Wed, 7 Dec 2022 21:05:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1670447112; x=1701983112; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=xkRIEZsfPNHm1we9jUTmjADIkuib8dcV8mLBeChD95I=; b=IWYYnlvHc9mF1KoOku7LxGUsWMvaXTVJLFDuVh8tGXXWUBHQ0sPIQ3eo Wve3jpPjHE4K5omC8hG4lTHxSDZ3canRok3fPtZfXDHcq6xzau4J14OqP VQw2K7OS+BAv3/hwOfiW7LeocDT2EbPuhDveX1ZjkuhGtoNWMjvVBGi6z qmU8S2mc0cvV6uj6XqrqavcIym/2m4RqcIrxh5R24EpNmcy26IC8CbK09 wkfA65Zb8Lhz3UY1XBXLQ2hok5/SP92k0jHID45krdM+zqfMEX7KW496z QfT9j1xRINR9i6hgZJcZuvdf8qYdic50NUsNPxHe62Gg4VjkQvtkLArM1 g==; X-IronPort-AV: E=McAfee;i="6500,9779,10554"; a="379172001" X-IronPort-AV: E=Sophos;i="5.96,225,1665471600"; d="scan'208";a="379172001" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Dec 2022 13:04:59 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10554"; a="597104632" X-IronPort-AV: E=Sophos;i="5.96,225,1665471600"; d="scan'208";a="597104632" Received: from mdnavare-mobl1.jf.intel.com ([10.165.21.203]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Dec 2022 13:04:59 -0800 Date: Wed, 7 Dec 2022 13:05:15 -0800 From: "Navare, Manasi" To: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Message-ID: <20221207210515.GA1306246@mdnavare-mobl1.jf.intel.com> References: <20221202134412.21943-1-ville.syrjala@linux.intel.com> <20221202134412.21943-3-ville.syrjala@linux.intel.com> <20221205203425.GA1209420@mdnavare-mobl1.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [Intel-gfx] [PATCH 2/4] drm/i915/vrr: Fix guardband/vblank exit length calculation for adl+ X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: intel-gfx@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Wed, Dec 07, 2022 at 05:10:54PM +0200, Ville Syrjälä wrote: > On Mon, Dec 05, 2022 at 12:34:25PM -0800, Navare, Manasi wrote: > > On Fri, Dec 02, 2022 at 03:44:10PM +0200, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > We are miscalculating both the guardband value, and the resulting > > > vblank exit length on adl+. This means that our start of vblank > > > (double buffered register latch point) is incorrect, and we also > > > think that it's not where it actually is (hence vblank evasion/etc. > > > may not work properly). Fix up the calculations to match the real > > > hardware behaviour (as reverse engineered by intel_display_poller). > > > > > > Signed-off-by: Ville Syrjälä > > > --- > > > drivers/gpu/drm/i915/display/intel_vrr.c | 6 +++--- > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c > > > index 6655dd2c1684..753e7b211708 100644 > > > --- a/drivers/gpu/drm/i915/display/intel_vrr.c > > > +++ b/drivers/gpu/drm/i915/display/intel_vrr.c > > > @@ -78,10 +78,10 @@ static int intel_vrr_vblank_exit_length(const struct intel_crtc_state *crtc_stat > > > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc); > > > struct drm_i915_private *i915 = to_i915(crtc->base.dev); > > > > > > - /* The hw imposes the extra scanline before frame start */ > > > if (DISPLAY_VER(i915) >= 13) > > > - return crtc_state->vrr.guardband + crtc_state->framestart_delay + 1; > > > + return crtc_state->vrr.guardband; > > > > This makes sense since with guardband, there is no framestart delay > > framestart delay is still a thing. But it's not something that > affects how the hardware interprets the guardband value. > > > > > > else > > > + /* The hw imposes the extra scanline before frame start */ > > > return crtc_state->vrr.pipeline_full + crtc_state->framestart_delay + 1; > > > } > > > > > > @@ -151,7 +151,7 @@ intel_vrr_compute_config(struct intel_crtc_state *crtc_state, > > > * number of scan lines. Assuming 0 for no DSB. > > > */ > > > crtc_state->vrr.guardband = > > > - crtc_state->vrr.vmin - adjusted_mode->crtc_vdisplay; > > > + crtc_state->vrr.vmin + 1 - adjusted_mode->crtc_vdisplay; > > > > Why are we adding + 1 here? The bspec says guardband should be : > > Guardband = Vmin - Vactive - Window2 where in our case Window2 = 0 > > If we need that + 1 to get this working, then perhaps we need to update > > Bspec? > > flipline is what actaully determines the start of vblank, and > 'flipline>=vmin+1' always. Flipline would be always >=vmin as per the bspec, have we tried with that or if that definitely doesnt work then we need to have this changed in the bspec. Either way if this is the only value that works then with this change added to bspec: Reviewed-by: Manasi Navare Manasi > > > > > I kind of want to see if this is still breaking if we dont have that + > > 1? > > Without it start of vblank happens one line later than where we want it > to happen. > > > > > Manasi > > > > > } else { > > > crtc_state->vrr.pipeline_full = > > > min(255, crtc_state->vrr.vmin - adjusted_mode->crtc_vdisplay - > > > -- > > > 2.37.4 > > > > > -- > Ville Syrjälä > Intel