linux-stable.git/drivers/gpu/drm/amd/display/modules/freesync/freesync.c, branch linux-5.4.y

drm/amd/display: Round calculated vtotal

2024-11-08T15:20:33+00:00

commit c03fca619fc687338a3b6511fdbed94096abdf79 upstream.

[WHY]
The calculated vtotal may has 1 line deviation. To get precisely
vtotal number, round the vtotal result.

Cc: Mario Limonciello 
Cc: Alex Deucher 
Cc: stable@vger.kernel.org
Reviewed-by: Anthony Koo 
Signed-off-by: Robin Chen 
Signed-off-by: Alex Hung 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: prevent potential division by zero errors

2023-10-10T19:46:38+00:00

[ Upstream commit 07e388aab042774f284a2ad75a70a194517cdad4 ]

There are two places in apply_below_the_range() where it's possible for
a divide by zero error to occur. So, to fix this make sure the divisor
is non-zero before attempting the computation in both cases.

Cc: stable@vger.kernel.org
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2637
Fixes: a463b263032f ("drm/amd/display: Fix frames_to_insert math")
Fixes: ded6119e825a ("drm/amd/display: Reinstate LFC optimization")
Reviewed-by: Aurabindo Pillai 
Signed-off-by: Hamza Mahfooz 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: Fix LFC multiplier changing erratically

2023-10-10T19:46:38+00:00

[ Upstream commit 575da8db31572d1d8de572d0b6ffb113624c2f8f ]

[Why]
1. There is a calculation that is using frame_time_in_us instead of
last_render_time_in_us to calculate whether choosing an LFC multiplier
would cause the inserted frame duration to be outside of range.

2. We do not handle unsigned integer subtraction correctly and it underflows
to a really large value, which causes some logic errors.

[How]
1. Fix logic to calculate 'within range' using last_render_time_in_us
2. Split out delta_from_mid_point_delta_in_us calculation to ensure
we don't underflow and wrap around

Signed-off-by: Anthony Koo 
Reviewed-by: Aric Cyr 
Acked-by: Qingqing Zhuo 
Signed-off-by: Alex Deucher 
Stable-dep-of: 07e388aab042 ("drm/amd/display: prevent potential division by zero errors")
Signed-off-by: Sasha Levin

drm/amd/display: Reinstate LFC optimization

2023-10-10T19:46:38+00:00

[ Upstream commit ded6119e825aaf0bfc7f2a578b549d610da852a7 ]

[why]
We want to streamline the calculations made when entering LFC.
Previously, the optimizations led to screen tearing and were backed out
to unblock development.

[how]
Integrate other calculations parameters, as well as screen tearing,
fixes with the original LFC calculation optimizations.

Signed-off-by: Amanda Liu 
Reviewed-by: Aric Cyr 
Acked-by: Rodrigo Siqueira 
Signed-off-by: Alex Deucher 
Stable-dep-of: 07e388aab042 ("drm/amd/display: prevent potential division by zero errors")
Signed-off-by: Sasha Levin

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