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

drm/amd/display: Refactoring VTEM

2019-08-23T16:41:58Z

[Why] Video Timing Extended Metadata packet (VTEM) is not specific to freesync. So move it out of freesync module [How] - Moved VTEM from freesync module to info_packet module - Created new structure for VTEM parameters that can be used for VRR and FVA Signed-off-by: Ahmad Othman Reviewed-by: Chris Park Acked-by: Ahmad Othman Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher

drm/amd/display: Fix frames_to_insert math

2019-08-15T15:53:12Z

[Why] The math on deciding on how many "frames to insert" sometimes sent us over the max refresh rate. Also integer overflow can occur if we have high refresh rates. [How] Instead of clipping the frame duration such that it doesn’t go below the min, just remove a frame from the number of frames to insert. + Use unsigned long long for intermediate calculations to prevent integer overflow. Signed-off-by: Bayan Zabihiyan Reviewed-by: Aric Cyr Acked-by: Leo Li Signed-off-by: Alex Deucher

drm/amd: drop use of drmp.h in os_types.h

2019-06-10T20:59:45Z

Drop use of the deprecated drmP.h from display/dc/os_types.h Fix all fallout after this change. Most of the fixes was adding a missing include of vmalloc.h. Signed-off-by: Sam Ravnborg Reviewed-by: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou" Cc: David Airlie Cc: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190609220757.10862-4-sam@ravnborg.org

drm/amd/display: Fix and simplify apply_below_the_range()

2019-04-29T19:59:35Z

The comparison of inserted_frame_duration_in_us against a duration calculated from max_refresh_in_uhz is both wrong in its math and not needed, as the min_duration_in_us value is already cached in in_out_vrr for reuse. No need to recalculate it wrongly at each invocation. Signed-off-by: Mario Kleiner Reviewed-by: Nicholas Kazlauskas Signed-off-by: Alex Deucher

drm/amd/display: Fix VTEM InfoPacket programming

2019-03-21T04:39:48Z

Refactor setting bit fields. Correcting the offset of MD0. Initializing the InfoPacket header fields. Defining the field offsets and masks. Signed-off-by: Reza Amini Reviewed-by: Anthony Koo Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher

drm/amd/display: Programming correct VRR_EN bit in VTEM structure

2019-03-21T04:39:48Z

[Why] In HDMI plugfest, MTK report our EMP with VRR_EN bit = 0. VRR_EN bit is EMP-MD0-bit 0. Currently driver set 1 to bit 3. [How] Programming correct VRR_EN bit in EMP-MD0-bit0. Signed-off-by: Hugo Hu Reviewed-by: Reza Amini Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher

drm/amd/display: Add a hysteresis to BTR frame multiplier

2019-03-21T04:39:48Z

[Why] Flickering is observed on some displays when the number of inserted BTR frames changes frequently. [How] Add in a margin of drift to prevent the inserted number of frames from jumping around too frequently. Signed-off-by: Aric Cyr Reviewed-by: Nicholas Kazlauskas Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher

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