linux/drivers/gpu/drm/amd/display/modules/freesync/freesync.c, branch v5.1

drm/amd/display: Pass app_tf by value rather than by reference

2019-02-28T03:23:55Z

Clang warns when an expression that equals zero is used as a null pointer constant (in lieu of NULL): drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4435:3: warning: expression which evaluates to zero treated as a null pointer constant of type 'const enum color_transfer_func *' [-Wnon-literal-null-conversion] TRANSFER_FUNC_UNKNOWN, ^~~~~~~~~~~~~~~~~~~~~ 1 warning generated. This warning is caused by commit bb47de736661 ("drm/amdgpu: Set FreeSync state using drm VRR properties") and it could be solved by using NULL instead of TRANSFER_FUNC_UNKNOWN or casting TRANSFER_FUNC_UNKNOWN as a pointer. However, after looking into it, there doesn't appear to be a good reason to pass app_tf by reference as it is never mutated along the way. This is the only code path in which app_tf is used: mod_freesync_build_vrr_infopacket -> build_vrr_infopacket_v2 -> build_vrr_infopacket_fs2_data Neither mod_freesync_build_vrr_infopacket or build_vrr_infopacket_v2 modify app_tf's value and build_vrr_infopacket_fs2_data expects just the value so we can avoid dereferencing anything by just passing in app_tf's value to mod_freesync_build_vrr_infopacket and build_vrr_infopacket_v2. There is no functional change because build_vrr_infopacket_fs2_data doesn't do anything if TRANSFER_FUNC_UNKNOWN is passed to it, the same as not calling build_vrr_infopacket_fs2_data at all like before this change when NULL was used for app_tf. Reviewed-by: Harry Wentland Signed-off-by: Nathan Chancellor Signed-off-by: Alex Deucher

drm/amd/display: Add new infopacket definition

2019-01-14T20:42:12Z

Modify freesync module to build VTEM infopackets when in HdmiVRR mode Signed-off-by: Bayan Zabihiyan Reviewed-by: Jun Lei Acked-by: Leo Li Signed-off-by: Alex Deucher

drm/amd/display: Use 100 Hz precision for pipe pixel clocks

2019-01-14T20:04:39Z

[Why] Users would like more accurate pixel clocks, especially for fractional "TV" frame rates like 59.94 Hz. [How] Store and communicate pixel clocks with 100 Hz accuracy from dc_crtc_timing through to BIOS command table setpixelclock call. Signed-off-by: Ken Chalmers Reviewed-by: Charlene Liu Acked-by: Leo Li Signed-off-by: Alex Deucher

drm/amd/display: Info frame cleanup

2018-11-30T17:02:28Z

* Use provided infopacket in stream (if valid) instead of reconstructing in set_vendor_info_packet() * Use proper format for enums * Use dc info packet struct instead Signed-off-by: Harmanprit Tatla Reviewed-by: Anthony Koo Acked-by: Krunoslav Kovac Acked-by: Leo Li Signed-off-by: Alex Deucher

drm/amd/display: Freesync does not engage on some displays

2018-11-05T19:20:41Z

[Why] Current render margin time is not sufficient to compute exit frame time for most monitors. [How] Declared render margin in FPS to compute a exit frame rate that is 4 FPS above the minimum FPS required to engage FreeSync. Also did code clean-up to remove redundancies. Signed-off-by: Harmanprit Tatla Reviewed-by: Anthony Koo Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher

drm/amd/display: Add color bit info to freesync infoframe

2018-09-27T02:09:05Z

Parse the native color bit and send it to freesync module for future use Signed-off-by: SivapiriyanKumarasamy Reviewed-by: Anthony Koo Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher

drm/amd/display: add config for sending VSIF

2018-08-27T16:10:56Z

Signed-off-by: Anthony Koo Reviewed-by: Aric Cyr Acked-by: Harry Wentland Signed-off-by: Alex Deucher

drm/amd/display: Correct rounding calcs in mod_freesync_is_valid_range

2018-08-27T16:10:55Z

Signed-off-by: Anthony Koo Reviewed-by: Aric Cyr Acked-by: Harry Wentland Signed-off-by: Alex Deucher

drm/amd/display: refactor vupdate interrupt registration

2018-08-27T16:10:54Z

We only need to register once OS calls the interrupt control. Also, if we are entering static screen mode, disable after ramping is done. Disable shall be done via timer of 2 seconds regardless of ramping complete or not, just to simplify. Also, ramp to mid instead of min, due to better flicker performance... Signed-off-by: Anthony Koo Reviewed-by: Aric Cyr Acked-by: Harry Wentland Signed-off-by: Alex Deucher

drm/amd/display: fix LFC tearing at top of screen

2018-08-27T16:10:54Z

Tearing occurred because new VTOTAL MIN/MAX was being programmed too early. The flip can happen within the VUPDATE high region, and the new min/max would take effect immediately. But this means that frame is not variable anymore, and tearing would occur when the flip actually happens. The fixed insert duration should be programmed on the first VUPDATE interrupt instead. Signed-off-by: Anthony Koo Reviewed-by: Aric Cyr Acked-by: Harry Wentland Signed-off-by: Alex Deucher