kernel/linux.git/drivers/gpu/drm/amd/display/modules/freesync, branch v5.4.26

drm/amd/display: Clear state after exiting fixed active VRR state

2020-02-24T07:36:28+00:00

[ Upstream commit 6f8f76444baf405bacb0591d97549a71a9aaa1ac ] [why] Upon exiting a fixed active VRR state, the state isn't cleared. This leads to the variable VRR range to be calculated incorrectly. [how] Set fixed active state to false when updating vrr params Signed-off-by: Amanda Liu Reviewed-by: Anthony Koo Acked-by: Harry Wentland Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: Properly round nominal frequency for SPD

2019-12-31T15:44:02+00:00

[ Upstream commit c59802313e84bede954235b3a5dd0dd5325f49c5 ] [Why] Some displays rely on the SPD verticle frequency maximum value. Must round the calculated refresh rate to the nearest integer. [How] Round the nominal calculated refresh rate to the nearest whole integer. Signed-off-by: Aric Cyr Reviewed-by: Anthony Koo Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: Refactoring VTEM

2019-08-23T16:41:58+00:00

[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:12+00:00

[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:45+00:00

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:35+00:00

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:48+00:00

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:48+00:00

[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:48+00:00

[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:55+00:00

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