Signed-off-by: NAric Cyr <aric.cyr@amd.com>
Reviewed-by: NAric Cyr <Aric.Cyr@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

pass SDP splitting when setting stream attributes for future use
Signed-off-by: NNikola Cornij <nikola.cornij@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Create dccg_init and init_clocks for future use
Signed-off-by: NEryk Brol <eryk.brol@amd.com>
Reviewed-by: NJun Lei <Jun.Lei@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
set_display_requirement, dcn1_pplib_apply_display_requirements
are no longer used and should be removed.
Signed-off-by: NFatemeh Darbehani <fatemeh.darbehani@amd.com>
Reviewed-by: NHersen Wu <hersenxs.wu@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[WHY]
The resource constructor currently needs num_virtual_links from
init_data but will need access to other items provided by DM.

[HOW]
Pass init_data into DCN create_resource_pool functions.
Signed-off-by: NHarry Wentland <harry.wentland@amd.com>
Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Acked-by: NHersen Wu <hersenxs.wu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
When you have a SST branch device the driver, Even no sink device connected,
it also send HPD with a valid EDID. Driver will config it to DP sink.
Therefore, there're two displays in display setting.

DPCD 0x05, DFP_PRESENT = 1 (branch device),
DFP_TYPE = 00 (Display Port)

[How]
Driver determine DPCD 0x05 DFP_PRESENT = 1(branch) as an active dongle
And check DFP count.
Signed-off-by: NHugo Hu <hugo.hu@amd.com>
Reviewed-by: NHugo Hu <Hugo.Hu@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

program default output gamma if no user specific gamma
parameters passed.
Signed-off-by: Nhersen wu <hersenxs.wu@amd.com>
Reviewed-by: NSun peng Li <Sunpeng.Li@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[why]
existing logic finds "first free pipe from 5 -> 0" to split
this will cause certain sequences to require DC to move
an MPCC from one tree to another, which is unsupported
this leads to blackscreen

to mitigate this problem, we will always try to acquire the
"preferred" pipe, and each pipe has a unique preferred pipe
this means we avoid most of the scenarios where
pipe splitting leads to moving MPCC from one tree
to another
Signed-off-by: NJun Lei <Jun.Lei@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Leads to an undefined symbol otherwise.
Reviewed-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

We want DRM planes to be initialized in the following order:

- primary planes
- overlay planes
- cursor planes

to support existing userspace expectations for plane z-ordering. This
means that we also need to register CRTCs after all planes have been
initialized since overlay planes can be placed on any CRTC.

So the only reason why we have the mode_info->planes list is to
remember the primary planes for use later when we need to register
the CRTC.

Overlay planes have no purpose being in this list. DRM will cleanup
any planes that we've registered for us, so the only planes that need to
be explicitly cleaned up are the ones that have failed to register.

By dropping the explicit free on every plane in the mode_info->planes
list this patch also fixes a double-free in the case where we fail to
initialize only some of the planes.

Cc: Leo Li <sunpeng.li@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
We need arbitrary read/write over DP AUX DPCD
for debugging

[How]
Three debugfs entries

Set the target address by writing to
"aux_dpcd_address"
(The first four bytes written are used)

Set the transaction size in bytes by writing to
"aux_dpcd_size"
(The first four bytes written are used)

Start a transaction by reading/writing
"aux_dpcd_data"

Do note: there is no concerrency protection at all
Accessing these entries in quick succession can lead
to strange behaviour
Signed-off-by: NDavid Francis <David.Francis@amd.com>
Reviewed-by: NHarry Wentland <Harry.Wentland@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
We need to add DP SDP message test debugfs to make sdp message test
more convenient and efficient.

[How]
Add sdp_message debugfs entry in amdgpu.
Signed-off-by: NLeo (Hanghong) Ma <hanghong.ma@amd.com>
Reviewed-by: NSun peng Li <Sunpeng.Li@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Acked-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
We need to add DP SDP message test debugfs to make sdp message test
more convenient and efficient.

[How]
Add a DM accessible SDP interface for custom data.
Signed-off-by: NLeo (Hanghong) Ma <hanghong.ma@amd.com>
Reviewed-by: NHarry Wentland <Harry.Wentland@amd.com>
Reviewed-by: NRoman Li <Roman.Li@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

There are issues removing surfaces/streams when odm is active.
This is a step to fix that
Signed-off-by: NDmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

A number of places opp programming was missing for odm second pipe.
This change fixes the oversight.
Signed-off-by: NDmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

We fail to reset the second odm combine pipe. This change fixes
odm pointer management.
Signed-off-by: NDmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Releasing planes should not release the 2nd odm pipe right away,
this change leaves us with 2 pipes with null planes and same stream
when planes are released during odm.
Signed-off-by: NDmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NAric Cyr <aric.cyr@amd.com>
Reviewed-by: NAric Cyr <Aric.Cyr@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Refactor setting bit fields. Correcting the offset of MD0.
Initializing the InfoPacket header fields. Defining the field offsets
and masks.
Signed-off-by: NReza Amini <Reza.Amini@amd.com>
Reviewed-by: NAnthony Koo <Anthony.Koo@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
In certain cases we do link training when we don't have a backend.

[How]
In dc_link_set_preferred_link_settings(), store preferred link settings
first and then verify that the link is DP and the link stream's backend is
enabled.  If either is false, then we will not do any link retraining.
Signed-off-by: NSamson Tam <Samson.Tam@amd.com>
Reviewed-by: NAric Cyr <Aric.Cyr@amd.com>
Acked-by: NAnthony Koo <Anthony.Koo@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Add these interfacese for future use
setup_global_lock()
lock_global()
pipe_control_lock_global()
Signed-off-by: NWenjing Liu <Wenjing.Liu@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NEric Bernstein <eric.bernstein@amd.com>
Reviewed-by: NNevenko Stupar <Nevenko.Stupar@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Currently we are missing a few checks to see if HDR10 is allowed.
In particular we never check for the extended colorimetry bit (whether its
present or set to 1). Further we don't read in the dpcd block in DC that
would provide these bits.

[How]
- Added in DC code to read in the block containing the extended colorimetry
bit.
Signed-off-by: NHarmanprit Tatla <Harmanprit.Tatla@amd.com>
Reviewed-by: NAnthony Koo <Anthony.Koo@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Somewhere in the atomic check reshuffle ABM got lost.
ABM is a crtc property (copied from a connector property).
It can change without a modeset, just like underscan.

[How]
In the skip_modeset branch of atomic check crtc updates,
copy over the abm property.
Signed-off-by: NDavid Francis <David.Francis@amd.com>
Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[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: NHugo Hu <hugo.hu@amd.com>
Reviewed-by: NReza Amini <Reza.Amini@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NAric Cyr <aric.cyr@amd.com>
Reviewed-by: NAric Cyr <Aric.Cyr@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[why]
There exist displays with EDIDs > 512 bytes, existing code
will cause us to ignore all extension blocks.
Signed-off-by: NJun Lei <Jun.Lei@amd.com>
Reviewed-by: NWenjing Liu <Wenjing.Liu@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Audio was unmuted for HDMI only, need to do so for DP as well.
Signed-off-by: NWesley Chalmers <Wesley.Chalmers@amd.com>
Reviewed-by: NChris Park <Chris.Park@amd.com>
Reviewed-by: NEric Bernstein <Eric.Bernstein@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[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: NAric Cyr <aric.cyr@amd.com>
Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Description]
when programming VID_TIMING, we were using the original VESA timing for DP_VIDM/N.
for YCbCr420 or compressed YCbCr422, using half rate as  YCbCr444.
Signed-off-by: NCharlene Liu <charlene.liu@amd.com>
Reviewed-by: NNikola Cornij <Nikola.Cornij@amd.com>
Acked-by: NLeo Li <sunpeng.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Need to set VID_N_MUL for 4:2:0 cases

[How]
Move setting to enc1_stream_encoder_dp_unblank and
ensure it is also set for non-4:2:0 cases.
Signed-off-by: NEric Bernstein <eric.bernstein@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Move out of header to dc_helper.c, in preparation for future
implementations.
Signed-off-by: NYongqiang Sun <yongqiang.sun@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
To help prevent plane state not being set to the correct default
value if any new properties are added in the future.

[How]
Use the drm helper - which seems to be the common solution among other
DRM drivers.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NSun peng Li <Sunpeng.Li@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

we were only checking the return value in one place, thus changing
generic_reg_wait from int to void and reading the register instead of
getting it from generic_reg_wait, when we need the return value.
Signed-off-by: NYongqiang Sun <yongqiang.sun@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
The plane_reset callback is subclassed but hasn't been updated since
the drm helper got updated to include resetting alpha related state
(state->alpha and state->pixel_blend_mode). The overlay planes
exposed by amdgpu_dm were therefore being rendered as invisible by
default ever since supported was exposed for alpha blending properties
on overlays.

This caused regressions in igt@kms_plane_multiple@atomic-tiling-none
and igt@kms_plane@plane-position-covered-pipe tests.

[How]
Reset the plane state values to their correct values as defined in
the drm helper.

This fixes the IGT test regression.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NHarry Wentland <Harry.Wentland@amd.com>
Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Incorrect hardcoded assumptions are made regarding luma and chroma
alignment. The actual values set for the DRM framebuffer should be used
when programming the address.

[How]
Respect the given pitch for both luma and chroma planes - it's not like
we can force the alignment to anything else at this point anyway.

Use the FB offset for the chroma planes directly. DRM already
provides this to us so there's no need to calculate it manually.

While we don't actually use the chroma surface size parameters on Raven,
these should have technically been fb->width / 2 and fb->height / 2
since the chroma plane is half size of the luma plane for NV12.

Leave a TODO indicating that those should be set based on the actual
surface format instead since this is only correct for YUV420 formats.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
For new DC planes the correct plane address fields are filled based
on whether the plane had a graphics or video format.

However, when we perform stream and plane updates using DC we only ever
fill in the graphics format fields. This causing corruption and hangs
when using video surface formats like NV12 for planes.

[How]
Use the same logic everywhere we update dc_plane_address - always
fill in the correct fields based on the surface format type.

There are 3 places this is done:

- Atomic check, during DC plane creation
- Atomic commit, during plane prepare_fb
- Atomic commit tail, during amdgpu_dm_commit_planes

We use the fill_plane_tiling_attributes in all 3 locations and it
already needs the address to update DCC attributes, so the surface
address update logic can be moved into this helper.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NLeo Li <sunpeng.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Cursor updates must acquire the pipe control lock to
prevent vupdate from triggering in the middle of cursor
programming. On DCN1 the pipe control lock prevents
pageflips from occurring. This means that a cursor update
right before vupdate can delay a pending pageflip

[How]
If the time until the next vupdate is less than a
conservative estimate of the cursor programming time,
wait until the vupdate has passed before locking.
Signed-off-by: NDavid Francis <David.Francis@amd.com>
Reviewed-by: NHarry Wentland <Harry.Wentland@amd.com>
Acked-by: NLeo Li <sunpeng.li@amd.com>
Acked-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[why]
We will not retry when EDID read failure using i2c over aux

[how]
treat i2c over aux failure the same as defer
Signed-off-by: NWenjing Liu <Wenjing.Liu@amd.com>
Reviewed-by: NDavid Francis <David.Francis@amd.com>
Acked-by: NLeo Li <sunpeng.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[why]
"reference clock" is a very overloaded variable in DC and causes confusion
as there are multiple sources of reference clock, which may be different values
incorrect input values to DML will cause DCHUB to be programmed improperly
and lead to hard to debug underflow issues

[how]
instead of using ref clock everywhere, specify WHICH ref clock:
- xtalin
- dccg refclk
- dchub refclk

these are all distinct values which may not be equal
Signed-off-by: NJun Lei <Jun.Lei@amd.com>
Reviewed-by: NYongqiang Sun <yongqiang.sun@amd.com>
Acked-by: NDavid Francis <David.Francis@amd.com>
Acked-by: NLeo Li <sunpeng.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>