On 2018-11-12 12:05 p.m., Kazlauskas, Nicholas wrote: > On 11/12/18 11:12 AM, 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@xxxxxxx> >>> Cc: Harry Wentland <harry.wentland@xxxxxxx> >>> Cc: Manasi Navare <manasi.d.navare@xxxxxxxxx> >>> Cc: Pekka Paalanen <ppaalanen@xxxxxxxxx> >>> Cc: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> >>> Cc: Michel Dänzer <michel@xxxxxxxxxxx> >> >> Looks good. Whole series is >> Reviewed-by: Harry Wentland <harry.wentland@xxxxxxx> >> >> How are we with the userspace patches? We should probably hold off pushing the kernel patches until the userspace work is all reviewed. >> >> Harry > > Thanks for the review. > > The xf86-video-amdgpu patches have been reviewed and the mesa patches > have been partially reviewed. > Alex, Michel, how do we merge changes like this that provide a kernel API that goes together with userspace changes? I imagine we'd want to get the kernel changes in first, and then merge the xf86-video-amdgpu and mesa changes. Please correct me if I'm wrong. Any objections to getting this merged via the usual amd-stg? Thanks, Harry > Nicholas Kazlauskas > >> >>> --- >>> 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 >>> > _______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
