AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Wentland, Harry" <Harry.Wentland@amd.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>,
	"michel@daenzer.net" <michel@daenzer.net>,
	"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>,
	"Kazlauskas, Nicholas" <Nicholas.Kazlauskas@amd.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v7 3/5] drm: Document variable refresh properties
Date: Tue, 27 Nov 2018 10:22:58 +0100	[thread overview]
Message-ID: <20181127092258.GA4266@phenom.ffwll.local> (raw)
In-Reply-To: <77ad01c4-4306-e150-c143-f52593b4656f@amd.com>

On Mon, Nov 12, 2018 at 04:12:10PM +0000, Wentland, Harry wrote:
> On 2018-11-08 9:43 a.m., Nicholas Kazlauskas wrote:
> > These include the drm_connector 'vrr_capable' and the drm_crtc
> > 'vrr_enabled' properties.
> > 
> > Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
> > Cc: Harry Wentland <harry.wentland@amd.com>
> > Cc: Manasi Navare <manasi.d.navare@intel.com>
> > Cc: Pekka Paalanen <ppaalanen@gmail.com>
> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Cc: Michel Dänzer <michel@daenzer.net>
> 
> Looks good. Whole series is
> Reviewed-by: Harry Wentland <harry.wentland@amd.com>
> 
> How are we with the userspace patches? We should probably hold off
> pushing the kernel patches until the userspace work is all reviewed.

Do some igts exist for this too? Especially for tricky pieces of uapi
having a non-vendor reference code somewhere would be good, aside from
testing and all that.
-Daniel

> 
> Harry
> 
> > ---
> >  Documentation/gpu/drm-kms.rst   |  7 ++++
> >  drivers/gpu/drm/drm_connector.c | 68 +++++++++++++++++++++++++++++++++
> >  2 files changed, 75 insertions(+)
> > 
> > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > index 4b1501b4835b..8da2a178cf85 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documentation/gpu/drm-kms.rst
> > @@ -575,6 +575,13 @@ Explicit Fencing Properties
> >  .. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c
> >     :doc: explicit fencing properties
> >  
> > +
> > +Variable Refresh Properties
> > +---------------------------
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_connector.c
> > +   :doc: Variable refresh properties
> > +
> >  Existing KMS Properties
> >  -----------------------
> >  
> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > index 49290060ab7b..0e4287461997 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1255,6 +1255,74 @@ int drm_mode_create_scaling_mode_property(struct drm_device *dev)
> >  }
> >  EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
> >  
> > +/**
> > + * DOC: Variable refresh properties
> > + *
> > + * Variable refresh rate capable displays can dynamically adjust their
> > + * refresh rate by extending the duration of their vertical front porch
> > + * until page flip or timeout occurs. This can reduce or remove stuttering
> > + * and latency in scenarios where the page flip does not align with the
> > + * vblank interval.
> > + *
> > + * An example scenario would be an application flipping at a constant rate
> > + * of 48Hz on a 60Hz display. The page flip will frequently miss the vblank
> > + * interval and the same contents will be displayed twice. This can be
> > + * observed as stuttering for content with motion.
> > + *
> > + * If variable refresh rate was active on a display that supported a
> > + * variable refresh range from 35Hz to 60Hz no stuttering would be observable
> > + * for the example scenario. The minimum supported variable refresh rate of
> > + * 35Hz is below the page flip frequency and the vertical front porch can
> > + * be extended until the page flip occurs. The vblank interval will be
> > + * directly aligned to the page flip rate.
> > + *
> > + * Not all userspace content is suitable for use with variable refresh rate.
> > + * Large and frequent changes in vertical front porch duration may worsen
> > + * perceived stuttering for input sensitive applications.
> > + *
> > + * Panel brightness will also vary with vertical front porch duration. Some
> > + * panels may have noticeable differences in brightness between the minimum
> > + * vertical front porch duration and the maximum vertical front porch duration.
> > + * Large and frequent changes in vertical front porch duration may produce
> > + * observable flickering for such panels.
> > + *
> > + * Userspace control for variable refresh rate is supported via properties
> > + * on the &drm_connector and &drm_crtc objects.
> > + *
> > + * "vrr_capable":
> > + *	Optional &drm_connector boolean property that drivers should attach
> > + *	with drm_connector_attach_vrr_capable_property() on connectors that
> > + *	could support variable refresh rates. Drivers should update the
> > + *	property value by calling drm_connector_set_vrr_capable_property().
> > + *
> > + *	Absence of the property should indicate absence of support.
> > + *
> > + * "vrr_enabled":
> > + *	Default &drm_crtc boolean property that notifies the driver that the
> > + *	content on the CRTC is suitable for variable refresh rate presentation.
> > + *	The driver will take this property as a hint to enable variable
> > + *	refresh rate support if the receiver supports it, ie. if the
> > + *	"vrr_capable" property is true on the &drm_connector object. The
> > + *	vertical front porch duration will be extended until page-flip or
> > + *	timeout when enabled.
> > + *
> > + *	The minimum vertical front porch duration is defined as the vertical
> > + *	front porch duration for the current mode.
> > + *
> > + *	The maximum vertical front porch duration is greater than or equal to
> > + *	the minimum vertical front porch duration. The duration is derived
> > + *	from the minimum supported variable refresh rate for the connector.
> > + *
> > + *	The driver may place further restrictions within these minimum
> > + *	and maximum bounds.
> > + *
> > + *	The semantics for the vertical blank timestamp differ when
> > + *	variable refresh rate is active. The vertical blank timestamp
> > + *	is defined to be an estimate using the current mode's fixed
> > + *	refresh rate timings. The semantics for the page-flip event
> > + *	timestamp remain the same.
> > + */
> > +
> >  /**
> >   * drm_connector_attach_vrr_capable_property - creates the
> >   * vrr_capable property
> > 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2018-11-27  9:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-08 14:43 [PATCH v7 0/5] A DRM API for adaptive sync and variable refresh rate support Nicholas Kazlauskas
     [not found] ` <20181108144353.31363-1-nicholas.kazlauskas-5C7GfCeVMHo@public.gmane.org>
2018-11-08 14:43   ` [PATCH v7 1/5] drm: Add vrr_capable property to the drm connector Nicholas Kazlauskas
2018-11-08 14:43   ` [PATCH v7 2/5] drm: Add vrr_enabled property to drm CRTC Nicholas Kazlauskas
     [not found]     ` <20181108144353.31363-3-nicholas.kazlauskas-5C7GfCeVMHo@public.gmane.org>
2019-01-30 10:42       ` Daniel Vetter
     [not found]         ` <CAKMK7uHjOvivvK1_5yFV3miR=xQx7NHta11_etBSkGfr+Aor-g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-01-30 11:02           ` Daniel Vetter
     [not found]             ` <CAKMK7uFcZWMbs98H3ks6yYMmjM7TVtaW4B4TVXMX8wSJMZbvVA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-01-30 13:37               ` Kazlauskas, Nicholas
2018-11-08 14:43   ` [PATCH v7 4/5] drm/amdgpu: Correct get_crtc_scanoutpos behavior when vpos >= vtotal Nicholas Kazlauskas
2018-11-08 14:43 ` [PATCH v7 3/5] drm: Document variable refresh properties Nicholas Kazlauskas
     [not found]   ` <20181108144353.31363-4-nicholas.kazlauskas-5C7GfCeVMHo@public.gmane.org>
2018-11-12 16:12     ` Wentland, Harry
     [not found]       ` <77ad01c4-4306-e150-c143-f52593b4656f-5C7GfCeVMHo@public.gmane.org>
2018-11-12 17:05         ` Kazlauskas, Nicholas
     [not found]           ` <58956653-ab01-55c8-abad-a6b8e270acd1-5C7GfCeVMHo@public.gmane.org>
2018-11-26 21:49             ` Wentland, Harry
     [not found]               ` <a3cc6477-37bc-40c5-8042-997a64d166e5-5C7GfCeVMHo@public.gmane.org>
2018-11-27  8:52                 ` Michel Dänzer
2018-11-27  9:22       ` Daniel Vetter [this message]
     [not found]         ` <20181127092258.GA4266-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2018-11-27 14:43           ` Wentland, Harry
2018-11-08 14:43 ` [PATCH v7 5/5] drm/amdgpu: Set FreeSync state using drm VRR properties Nicholas Kazlauskas

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=20181127092258.GA4266@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=Harry.Wentland@amd.com \
    --cc=Nicholas.Kazlauskas@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=manasi.d.navare@intel.com \
    --cc=michel@daenzer.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox