[why]
Enable Freesync over PCon on Linux environment.

[how]
Adding Freesync over PCon support in amdgpu_dm
- Read DPCD for Freesync over PCon capabilitiy
- Add whitelist for compatible branch devices

Reviewed-by: Chao-kai Wang <Stylon.Wang@amd.com>
Acked-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Sung Joon Kim <sungkim@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

[why]
Start enabling AdaptiveSync feature on Linux environment.

[how]
Adding AdaptiveSync support in DC layer
- building AdaptiveSync info_packets
- adjusting the v_startup parameter

Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Alan Liu <HaoPing.Liu@amd.com>
Signed-off-by: Sung Joon Kim <sungjoon.kim@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

[Why]
For FreeSync HDR, native color space flag in AMD VSIF(BT.709) should be
used when intepreting content and color space flag in VSC or AVI
infoFrame should be ignored. However, it turned out some userspace
application still use color flag in VSC or AVI infoFrame which is
incorrect.

[How]
Transfer function is used when building the VSC and AVI infoFrame. Set
colorimetry to BT.709 when all the following match:

1. Pixel format is YCbCr;
2. In FreeSync 2 HDR, color is COLOR_SPACE_2020_YCBCR;
3. Transfer function is TRANSFER_FUNC_GAMMA_22;

Tested-by: Mark Broadworth <mark.broadworth@amd.com>
Reviewed-by: Krunoslav Kovac <Krunoslav.Kovac@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Ma Hanghong <hanghong.ma@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

[why & how]
We need to implement the VSC packet rev4 that is required by PSRSU.

Follow the eDP 1.5 spec pg. 257

changes in v2:
-------------------
- set vsc packet rev2 for PSR1

Cc: Chandan Vurdigerenataraj <chandan.vurdigerenataraj@amd.com>

Signed-off-by: David Zhang <dingchen.zhang@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

[Why & How]
The latest HDMI SPEC has updated the VTEM packet structure,
so change the VTEM Infopacket defined in the driver side to align
with the SPEC.

Reviewed-by: Chris Park <Chris.Park@amd.com>
Acked-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Leo (Hanghong) Ma <hanghong.ma@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

[why]
OnSetSourceContentAttribute it does not trigger an update for the VSC
with TF change.

[how]
In this call, create a new VSC infoPacket based on the new config, and
allow DisplayTarget decide if an update and pursuant passive flip is
necessary

Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Krunoslav Kovac <Krunoslav.Kovac@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Reza Amini <Reza.Amini@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/../display/modules/info_packet/info_packet.c:412: warning: Cannot understand  *****************************************************************************

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

[Why]
Current function excludes the logic to generate H14b-VSIF. Now it
constructs HF-VSIF only and causes HDMI compliace test fail.

[How]
According to HDMI spec, source devices shall utilize the H14b-VSIF
whenever the signaling capabilities of the H14b-VSIF allow this.

Here keep the logic for HF-VSIF and add H14b-VSIF construction part.

Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
Reviewed-by: Roman Li <Roman.Li@amd.com>
Acked-by: Eryk Brol <eryk.brol@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

[Why]
Make a separation of what belongs in the differen dmub
headers

dmub_srv.h is for exposing dmub srv interface to rest of
driver.

other headers inside dmub/inc exposes cmds and definitions
that are owned by the firmware

[How]
keep firmware owned definitions in dmub/inc

move stuff that is purely driver interface headers to dmub/
since those are interface calls that are defined for rest of
driver to use

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>
Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

[Why]
For a type like PSR version, it makes sense for most of the code
to include a dc type, instead of having this a fw type define since
this is a capability and type exposed by dc.

Especially if it doesn't even need to communicate with the fw.

The code that is packing the firmware command message
should be the one who needs to translate the psr version
into a command that the firmware understands.

[How]
Add a dc_psr_version enum.

Signed-off-by: Anthony Koo <Anthony.Koo@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>