linux.git/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h, branch v5.8 Linux kernel source tree drm/amd/display: Change infopacket type programming 2020-04-22T22:11:47+00:00 Haiyi Zhou haiyi.zhou@amd.com 2020-04-03T14:00:58+00:00 d2bacc38f6caa96e6d67d2e3e2bd0aee36de6954 [Why] Certain displays may experience blanking if infopacket max range does not equal nominal refresh rate. [How] Add additional infopacket versions to program range to full or forced range in freesync states. This does not change the vrr logic. Signed-off-by: Haiyi Zhou <haiyi.zhou@amd.com> Reviewed-by: Anthony Koo <Anthony.Koo@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[Why]
Certain displays may experience blanking if infopacket max range does
not equal nominal refresh rate.

[How]
Add additional infopacket versions to program range to full or forced
range in freesync states.
This does not change the vrr logic.

Signed-off-by: Haiyi Zhou <haiyi.zhou@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Reinstate LFC optimization 2019-12-18T21:09:08+00:00 Amanda Liu amanda.liu@amd.com 2019-11-21T21:06:57+00:00 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 <amanda.liu@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[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 <amanda.liu@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Fix screen tearing on vrr tests 2019-12-05T23:22:40+00:00 Amanda Liu amanda.liu@amd.com 2019-11-15T22:07:27+00:00 dd0b162fd00915728860a360c97752988782b8cc [Why] Screen tearing is present in tests when setting the frame rate to certain fps [How] Revert previous optimizations for low frame rates. Signed-off-by: Amanda Liu <amanda.liu@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[Why]
Screen tearing is present in tests when setting the frame rate to
certain fps

[How]
Revert previous optimizations for low frame rates.

Signed-off-by: Amanda Liu <amanda.liu@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Improve LFC behaviour 2019-10-03T14:10:58+00:00 Aric Cyr aric.cyr@amd.com 2019-09-03T22:18:08+00:00 bb2746ac9143fe57adab57c30d19718dbaed7901 [Why] There can be some unsynchronized frames when entering/exiting LFC. This may cause tearing or stuttering at such transitions. [How] Add a enter/exit margin to algorithm to smoothly transition into and out of LFC without desynchronizing frames. Signed-off-by: Aric Cyr <aric.cyr@amd.com> Reviewed-by: Reza Amini <Reza.Amini@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Acked-by: Sivapiriyan Kumarasamy <Sivapiriyan.Kumarasamy@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[Why]
There can be some unsynchronized frames when entering/exiting
LFC.  This may cause tearing or stuttering at such transitions.

[How]
Add a enter/exit margin to algorithm to smoothly transition into
and out of LFC without desynchronizing frames.

Signed-off-by: Aric Cyr <aric.cyr@amd.com>
Reviewed-by: Reza Amini <Reza.Amini@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Acked-by: Sivapiriyan Kumarasamy <Sivapiriyan.Kumarasamy@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Refactoring VTEM 2019-08-23T16:41:58+00:00 Ahmad Othman ahmad.othman@amd.com 2019-08-01T19:05:27+00:00 a9f54ce3c6032361d2b69910114b6e8baf9bdf49 [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 <ahmad.othman@amd.com> Reviewed-by: Chris Park <Chris.Park@amd.com> Acked-by: Ahmad Othman <Ahmad.Othman@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[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 <ahmad.othman@amd.com>
Reviewed-by: Chris Park <Chris.Park@amd.com>
Acked-by: Ahmad Othman <Ahmad.Othman@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Pass app_tf by value rather than by reference 2019-02-28T03:23:55+00:00 Nathan Chancellor natechancellor@gmail.com 2018-12-10T23:42:01+00:00 672e78cab819ebe31e3b9b8abac367be8a110472 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 <harry.wentland@amd.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
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 <harry.wentland@amd.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Add new infopacket definition 2019-01-14T20:42:12+00:00 Bayan Zabihiyan Bayan.Zabihiyan@amd.com 2018-12-27T13:43:45+00:00 ca35899c4e3a173c0d6d4619dc62e836a9487cb2 Modify freesync module to build VTEM infopackets when in HdmiVRR mode Signed-off-by: Bayan Zabihiyan <Bayan.Zabihiyan@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
Modify freesync module to build VTEM infopackets when in HdmiVRR mode

Signed-off-by: Bayan Zabihiyan <Bayan.Zabihiyan@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Add color bit info to freesync infoframe 2018-09-27T02:09:05+00:00 SivapiriyanKumarasamy sivapiriyan.kumarasamy@amd.com 2018-08-30T13:37:22+00:00 c2791297013e531d1b7d8e17722bebec69386ab2 Parse the native color bit and send it to freesync module for future use Signed-off-by: SivapiriyanKumarasamy <sivapiriyan.kumarasamy@amd.com> Reviewed-by: Anthony Koo <Anthony.Koo@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
Parse the native color bit and send it to freesync module for future
use

Signed-off-by: SivapiriyanKumarasamy <sivapiriyan.kumarasamy@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: add config for sending VSIF 2018-08-27T16:10:56+00:00 Anthony Koo Anthony.Koo@amd.com 2018-05-08T21:09:49+00:00 69ff884526742fcb00b7509461bf8e41c87d9b10 Signed-off-by: Anthony Koo <Anthony.Koo@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
Signed-off-by: Anthony Koo <Anthony.Koo@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Fix bug where refresh rate becomes fixed 2018-08-27T16:10:52+00:00 Anthony Koo Anthony.Koo@amd.com 2018-04-05T01:01:21+00:00 ff6014d63a87d9a801ddd9ddd10359b2dead6943 This issue occurs if refresh rate range is very small and lfc is not used. When frame spikes occur, refresh rate becomes fixed and will not restore properly Signed-off-by: Anthony Koo <Anthony.Koo@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
This issue occurs if refresh rate range is very small and lfc is not used.
When frame spikes occur, refresh rate becomes fixed and will not restore properly

Signed-off-by: Anthony Koo <Anthony.Koo@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>