[Why]
Starting with DCN1, the input_pixel_processor (ipp) struct has been
replaced by dpp struct (part of DAL3.1 SW architecture change).
Need to update logic to handle cases where ipp is never allocated.

[How]
Only skip cursor position programming if both ipp and dpp resources
are NULL.
Signed-off-by: NEric Bernstein <eric.bernstein@amd.com>
Reviewed-by: NDmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Acked-by: NLeo Li <sunpeng.li@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: NLeo Li <sunpeng.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Power down of PHY on eDP requires us to call eDP power
control to power on again

[How]
1. In the case link rates don't match, disable PHY
requires calling of eDP power control ON after

2. Link disable case limit to eDP path since
this is not really applicable to DP since we do
power down PHY as part of verify link cap

3. Move detection of eDP link settings to be
done even for S4 resume cases where other
dpcd cap read and edid read can be skipped
Signed-off-by: NAnthony Koo <Anthony.Koo@amd.com>
Reviewed-by: NJun Lei <Jun.Lei@amd.com>
Acked-by: NAric Cyr <Aric.Cyr@amd.com>
Acked-by: NLeo Li <sunpeng.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Some DMCU messages were being sent in cases where
there was no DMCU FW at all, which resulted in some wait
timeouts

[How]
Delay sending some of the DMCU messages after FW
init is called and DMCU is running.
Signed-off-by: NAnthony Koo <Anthony.Koo@amd.com>
Reviewed-by: NAric Cyr <Aric.Cyr@amd.com>
Acked-by: NLeo Li <sunpeng.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

We'll need the ability to copy a dc_stream_state for some features.
Implement it here.
Signed-off-by: NWenjing Liu <Wenjing.Liu@amd.com>
Reviewed-by: NJun Lei <Jun.Lei@amd.com>
Acked-by: NLeo Li <sunpeng.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Workaround was missing in one HW disable path,
meaning when all pipes are power gated, stutter was
not working

[How]
Add workaround for init_hw path for stutter
workaround
Signed-off-by: NAnthony Koo <Anthony.Koo@amd.com>
Reviewed-by: NAric Cyr <Aric.Cyr@amd.com>
Acked-by: NLeo Li <sunpeng.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

smu.ppt_funcs is only initialized for ASICs supporting SW SMU.

On a Hawaii ASIC, attempting to access the udev attribute
ATTRS{power_dpm_state} will cause a null pointer deref in
amdgpu_get_dpm_state() because of this.

Fix by checking if SW SMU is supported first.
Signed-off-by: NLeo Li <sunpeng.li@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

They will be used by DC when runing ASIC-specific HUBP initialization.
Signed-off-by: NLeo Li <sunpeng.li@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Patch '5edb0c9b Fix deadlock with display during hanged ring recovery'
was accidentaly removed during one of DALs code merges.
Signed-off-by: NAndrey Grodzovsky <andrey.grodzovsky@amd.com>
Reviewed-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Don't block others while waiting for the fences to finish, concurrent
submission is perfectly valid in this case and holding the lock can
prevent killed applications from terminating.
Signed-off-by: NChristian König <ckoenig.leichtzumerken@gmail.com>
Reviewed-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

It's normal for VRAM to lost during GPU reset and so change
the log level to INFO to avoid confusing users.
Signed-off-by: NAndrey Grodzovsky <andrey.grodzovsky@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

enable UMDPSTATE support to force performance level for raven2.

v2: squash in warning fix (Alex)
Signed-off-by: NChengming Gui <Jack.Gui@amd.com>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The power profile allows the user to adjust the power state
heuristics for clock level transitions.

v2: squash in warning fix (Alex)
Reviewed-by: NEvan Quan <evan.quan@amd.com>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NChengming Gui <Jack.Gui@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

There is a spelling mistake in a pr_err message. Fix it.
Reviewed-by: NMukesh Ojha <mojha@codeaurora.org>
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

There is a spelling mistake in a DRM_INFO message. Fix it.
Reviewed-by: NMukesh Ojha <mojha@codeaurora.org>
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Enable MGCG for picasso.
Signed-off-by: NLikun Gao <Likun.Gao@amd.com>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Under SRIOV, we need disable DRIVER_ATOMIC.
Otherwise, it will trigger WARN_ON at drm_universal_plane_init.
Signed-off-by: NYintian Tao <yttao@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

amdgpu_bo_destroy had a bug by calling amdgpu_bo_unref outside mutex_lock.
If amdgpu_device_recover_vram executed between amdgpu_bo_unref and list_del_init,
it would get NULL of shadow->parent, then caused Call Trace and GPU reset failed.
Signed-off-by: NWentao Lou <Wentao.Lou@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This is needed by DC to support EDID emulation on USB-C ports.

CC: Samson Tam <Samson.Tam@amd.com>
CC: Harry Wentland <harry.wentland@amd.com>
CC: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: NLeo Li <sunpeng.li@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Method of getting firmware version is the same across ASICs, so remove
them from ASIC-specific files and create one in amdgpu_amdkfd.c. This new
created get_fw_version simply reads fw_version from adev->gfx than parsing
the ucode header.
Signed-off-by: NAmber Lin <Amber.Lin@amd.com>
Reviewed-by: NFelix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Send message with parameter to SMC to set xgmi pstate
Signed-off-by: Nshaoyunl <shaoyun.liu@amd.com>
Reviewed-by: NEvan Quan <evan.quan@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

DC and DM already support DRM_FORMAT_RGB565, it's just missing from the
list of valid formats.

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

PSP SOS firmware needs to be 0x80067 or later.
Signed-off-by: NEvan Quan <evan.quan@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
We used this change to investigate the performance of bandwidth validation,
it will be useful to have if we need to investigate further.

[How]
We use performance counter tick numbers to profile performance, they live
at dc->debug.bw_val_profile (set .enable in debugger to turn on measuring).
Signed-off-by: NJoshua Aberback <joshua.aberback@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Add a fast_validate parameter in dc_validate_global_state for future use
Signed-off-by: NJoshua Aberback <joshua.aberback@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
As long as we have at least one non-cursor plane enabled on a CRTC then
the CRTC itself can remain enabled.

This will allow for commits where there's an overlay plane enabled but
no primary plane enabled.

[How]
Remove existing primary plane fb != NULL checks and replace them with
the new does_crtc_have_active_plane helper.

This will be called from atomic check when validating the CRTC.

Since the primary plane state can now potentially be NULL we'll need
to guard for that when accessing it in some of the cursor logic.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NDavid Francis <David.Francis@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Surface scaling info updates can affect bandwidth and blocks. We need
to be checking these with global validation to avoid underflow or
corruption.

[How]
Drop the state->allow_modeset early exit in
dm_determine_update_type_for_commit. Most of those should be considered
fast now anyway.

Fill in scaling info and it to the surface update in atomic
check.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NDavid Francis <David.Francis@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
DM thinks that the update type should be full whenever a stream or
plane is added or removed (including recreations).

This won't match in the case where DC thinks what looks like a fast
update to DM is actually a medium or full - like scaling changes that
affect bandwidth and clocks.

[How]
Drop this warning. DC knows better than the DM does for determining
cases like this.

The other warning can be kept for now since it would warn on a pretty
serious DC or DM bug.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NDavid Francis <David.Francis@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
DC expects the surface memory address to identify the surface.

This doesn't work with what we're doing with the temporary surfaces,
it will always assume this is a full update because the surface
isn't in the current context.

[How]
Use the surface directly. This doesn't give us much improvement yet,
since we always create a new dc_plane_state when state->allow_modeset
is true.

The call into dc_check_update_surfaces_for_stream also needs to be
locked, for two reasons:

1. It checks the current DC state
2. It modifies the surface update flags

Both of which could be currently in the middle of commit work from
commit tail.

A TODO here is to pass the context explicitly into this function and
find a way to get the surface update flags out of it without modifying
the surface in place.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NDavid Francis <David.Francis@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Planes have downscaling limits and upscaling limits per format and DM
is expected to validate these using DC caps. We should fail atomic
check validation if we aren't capable of doing the scaling.

[How]
We don't currently create store which DC plane maps to which DRM plane
so we can't easily check the caps directly. For now add basic
constraints that cover the absolute min and max downscale / upscale
limits for most RGB and YUV formats across ASICs.

Leave a TODO indicating that these should really be done with DC caps.
We'll probably need to subclass DRM planes again in order to correctly
identify which DC plane maps to it.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NHarry Wentland <Harry.Wentland@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
DM doesn't need to know which link cap is being retrieved ( verified
 or preferred ).  Let DC figure it out.

[How]
Change name.
Signed-off-by: NSamson Tam <Samson.Tam@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
We currently don't do DC validation for medium or full updates where
the plane state isn't created. There are some medium and full updates
that can cause bandwidth or clock changes to occur resulting in
underflow or corruption.

We need to be able to fill surface and plane info updates during
atomic commit for dm_determine_update_type for commit. Since we already
do this during atomic commit tail it would be good if we had the same
logic in both places for creating these structures.

[How]
Introduce fill_dc_scaling_info and fill_dc_plane_info_and_addr.
These two functions cover the following three update structures:

- struct dc_scaling_info
- struct dc_plane_info
- struct dc_plane_address

Cleanup and adapter the existing fill_plane_* helpers to work with
these functions.

Update call sites that used most of these sub helpers directly to work
with the new functions. The exception being prepare_fb - we just want
the new buffer attributes specifically in the case where we're
creating the plane. This is needed for dc_commit_state in the case
where the FB hasn't been previously been used.

This isn't quite a refactor, but functionally driver behavior should
be mostly the smae as before. The one exception is that we now check
the return code for fill_plane_buffer_attributes which means that
commits will be rejected that try to enable DCC with erroneous
parameters.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NDavid Francis <David.Francis@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Pitch was only calculated based on format whenever the plane state
was recreated. This could result in surface corruption due to the
incorrect pitch being programmed when the surface pitch changed during
commits where state->allow_modeset = false.

[How]
Recalculate pitch at the same time we update the buffer address and
other buffer attributes. This function was previously called
fill_plane_tiling_attributes but I've also renamed it to
fill_plane_buffer_attributes to clarify the actual intent of the
function now that it's handling most buffer related attributes.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NDavid Francis <David.Francis@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
The overlay will be incorrectly placed *below* the primary plane for
commits with state->allow_modeset = true because the primary plane
won't be removed and recreated in the same commit.

[How]
Add the should_reset_plane helper to determine if the plane should be
reset or not. If we need to add or force reset any plane in the context
then we'll need to do the same for every plane on the stream.

Unfortunately we need to do the remove / recreate routine for removing
planes as well since DC currently isn't well equipped to handle the
plane with the top pipe being removed with other planes still active.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NSun peng Li <Sunpeng.Li@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Plane scaling parameters are not correctly filled or updated when
performing fast updates.

They're filled when creating the dc plane state and during atomic check.

While the atomic check code path happens for the plane even during fast
updates, the issue is that they're done in place on the dc_plane_state
directly. This dc_plane_state may be the current state plane state
being used by the hardware, so these parameters won't be correctly
programmed.

The new scaling parameters should instead be passed as an update
to the plane.

[How]
Update fill_rects_from_plane_state to not modify dc_plane_state
directly. Update the call sites that use this to fill in the appropriate
values.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NSun peng Li <Sunpeng.Li@amd.com>
Acked-by: Bhawanpreet 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: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Unlike external DP panels, internal eDP does not perform
verify link caps because the panel connection is fixed.

So if GOP enabled the eDP at boot, we can retain its
trained link settings to optimize.

[How]
Read the lane count and link rate by reading this
information from DPCD 100h, 101h, 115h
Signed-off-by: NAnthony Koo <Anthony.Koo@amd.com>
Reviewed-by: NAric Cyr <Aric.Cyr@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NYongqiang Sun <yongqiang.sun@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
dc_stream_get_crtc_position can return false.
This was unhandled in delay_cursor_until_vupdate

[How]
If dc_stream_get_crtc_position returns false, something
is weird.  Don't delay.
Signed-off-by: NDavid Francis <David.Francis@amd.com>
Reviewed-by: NSun peng Li <Sunpeng.Li@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[why]
there are some scaling capabilities such as fp16 which are known to be unsupported
on a given ASIC.  exposing these static capabilities allows much simpler implementation
for OS interfaces which require to report such static capabilities to reduce the
number of dynamic validation calls

[how]
refactor the existing plane caps to be more extensible, and add fp16 and scaling
capabilities
Signed-off-by: NJun Lei <Jun.Lei@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com>
Acked-by: NHarry Wentland <Harry.Wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>