[Why]
Many userspace applications (and IGT) seem to expect that most drivers
can keep a CRTC active and enabled if there are no primary or overlay
planes.

DC is setup to handle this but only in the case where there are
absolutely no planes on the CRTC - no primary, cursor, or overlay.

[How]
Add a check to reject commits that have cursor planes enabled and
nothing else on CRTCs since we can't handle that. The new helper
does_crtc_have_active_cursor is used for this.

In atomic commit tail, we need to let DC know that there are zero
planes enabled when doing stream updates to let it disable and blank
pipes as appropriate.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@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]
When disabling all the pipes for a CRTC the page-flip interrupt also
gets disabled on Raven. We can't re-enable the page-flip interrupt
unless we give DC at least one active DC plane.

We currently enable interrupts after the call to dc_commit_state since
there's currently no valid sequence that should disable all the planes
or re-enable planes for a CRTC without first going through
dc_commit_state.

If we were to allow for a CRTC to be enabled with no primary plane this
would not be the case - the call to dc_commit_updates_for_stream would
enable the planes when going from zero to at least one active plane,
but manage_dm_interrupts would have been called too early.

This results in a page-flip timeout on any subsequent commits since we
think the page-flip are now enabled when they're actually disabled.

We need to enable interrupts after the call to
dc_commit_updates_for_stream.

[How]
Split enabling interrupts into two passes. One pass before
dc_commit_updates_for_stream and one after it.

Shifting all the interrupts to be strictly below the call doesn't
currently work even though it should in theory. We end up queuing
off the vblank event to be handle by the flip handler before it's
actually enabled in some cases, particularly:

old_crtc_state->active = false -> new_crtc_state->active = true

The framebuffer states haven't changed and we can technically still
do a "pageflip" in this case and send back the event.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@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]
We only currently drop the vblank reference when the stream is
being removed from the context. We should be dropping it whenever we
disable interrupts and reaquiring it after we re-enable them.

We also never get the extra reference correctly when re-enabling
interrupts, since grabbing the reference has the following condition:

if (!crtc_state->crc_enabled && enable)
        drm_crtc_vblank_get(crtc);

This means that crc_enabled must be *false* in order to grab the extra
reference.

[How]
Always drop the ref whenever we're disabling interrupts.

Only disable CRC capture when the stream is being removed.

Always grab the ref by setting dm_new_crtc_state->crc_enabled = false
before the call to re-enable CRC capture.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@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]
We can't do cursor programming after the planes have been disabled
since there won't be any pipes - leading to lock warnings and the wrong
cursor state being left in the registers.

When we re-enable the planes after the previous cursor state will also
remain if we don't have a cursor plane.

[How]
If we're disabling the planes then do the cursor programming first.
If we're not disabling the planes then do the cursor programming after.

Introduce the amdgpu_dm_commit_cursors helper to avoid code duplication
for both of these cases.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@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]
The vblank and pageflip interrupts should only be enabled for a CRTC
that's enabled and has active planes.

The current logic takes care of this, but isn't setup to handle the case
where the active plane count goes to zero but the stream remains
enabled.

We currently block this case since we don't allow commits that enable a
CRTC with no active planes, but shouldn't be any reason we can't support
this from a hardware perspective and many userspace applications expect
to be able to do it (like IGT).

[How]
The count_crtc_active_planes function fills in the number of
"active_planes" on the dm_crtc_state. This should be the same as
DC's plane_count on the stream_status but easier to access since we
don't need to lock the private atomic state with the DC context.

Add the "interrupts_enabled" flag to the dm_crtc_state and set it based
on whether the stream exists and if there are active planes on the
stream.

Update the disable and enable logic to make use of this new flag.

There shouldn't be any functional change (yet) with this patch.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@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>

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>

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>

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]
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>

[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>

[Why]
We need DC's color space to match the color encoding and color space
specified by userspace to correctly render YUV surfaces.

[How]
Add the DRM color properties when the DC plane supports NV12.
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]
Hardware can support video surfaces and DC tells us which planes are
suitable via DC plane caps.

[How]
The supported formats array will now vary based on what DC tells us,
so create an array and fill it dynamically based on plane types and
caps.

Ideally we'd query support for every format via DC plane caps, but for
the framework is in place to do so later with this.
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]
When deciding to add properties or expose formats on DRM planes we
should be querying the caps for the DC plane it's supposed to represent.

[How]
Pass plane caps down into plane initialization, refactoring overlay
plane initialization to have the overlay plane be represented by
the first overlay capable DC plane.
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]

When entering S3, amdgpu first calls DRM to cache the current atomic
state, then commit the 'all-disabled' state. This sets dc->current_state
to point at the private atomic object's dm_atomic_state->context, as
any regular atomic commit would.

Afterwards, amdgpu_dm calls dc_set_power_state() with S3 power state.
This invalidates dc->current_state by wiping it to 0, consequently
wiping dm_atomic_state->context.

During resume, the cached atomic state is restored. When getting the
private object however, the dm_atomic_state - containing the wiped
context - is duplicated into the atomic state. This causes DC validation
to fail during atomic check, as necessary function pointers in dc_state
are now NULL.

[How]

Recreate the private object's dm_atomic_state->context during resume,
restoring any static values such as function pointers.

A TODO item is added to move static read-only values out of dc_state -
they shouldn't be there anyways.
Signed-off-by: NLeo Li <sunpeng.li@amd.com>
Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
We need DC's color space to match the color encoding and color space
specified by userspace to correctly render YUV surfaces.

[How]
Convert the DRM color encoding and color range properties to the
appropriate DC colorspace option and update the color space when
performing surface updates.
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>

The brace initialization used here generates warnings on some
compilers. For example, on GCC 4.9:

[...] In function ‘dm_determine_update_type_for_commit’:
[...] error: missing braces around initializer [-Werror=missing-braces]
   struct dc_stream_update stream_update = { 0 };
          ^

Use memset to make this more portable.

v2: Specify the compiler / diagnostic in the commit message (Paul)

Cc: Sun peng Li <Sunpeng.Li@amd.com>
Cc: Harry Wentland <Harry.Wentland@amd.com>
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]
Multiple threads were writing back to one global VBA in DC resulting
in multiple threads overwriting eachother's data

[How]
Add an instance of DML (which contains VBA) to each context and
change all calls that used dc->dml to use context->dml. Created a
seperate copy constructor for linux in a case where there is no
access to DC.
Signed-off-by: NAidan Wood <Aidan.Wood@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>

We want vblank counts and timestamps of flip completion as sent
in pageflip completion events to be consistent with the vblank
count and timestamp of the vblank of flip completion, like in non
VRR mode.

In VRR mode, drm_update_vblank_count() - and thereby vblank
count and timestamp updates - must be delayed until after the
end of front-porch of each vblank, as it is only safe to
calculate vblank timestamps outside of the front-porch, when
we actually know when the vblank will end or has ended.

The function drm_update_vblank_count() which updates timestamps
and counts gets called by drm_crtc_accurate_vblank_count() or by
drm_crtc_handle_vblank().

Therefore we must make sure that pageflip events for a completed
flip are only sent out after drm_crtc_accurate_vblank_count() or
drm_crtc_handle_vblank() is executed, after end of front-porch
for the vblank of flip completion.

Two cases:

a) Pageflip irq handler executes inside front-porch:
   In this case we must defer sending pageflip events until
   drm_crtc_handle_vblank() executes after end of front-porch,
   and thereby calculates proper vblank count and timestamp.
   Iow. the pflip irq handler must just arm a pageflip event
   to be sent out by drm_crtc_handle_vblank() later on.

b) Pageflip irq handler executes after end of front-porch, e.g.,
   after flip completion in back-porch or due to a massively
   delayed handler invocation into the active scanout of the new
   frame. In this case we can call drm_crtc_accurate_vblank_count()
   to safely force calculation of a proper vblank count and
   timestamp, and must send the pageflip completion event
   ourselves from the pageflip irq handler.

   This is the same behaviour as needed for standard fixed refresh
   rate mode.

To decide from within pageflip handler if we are in case a) or b),
we check the current scanout position against the boundary of
front-porch. In non-VRR mode we just do what we did in the past.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

In VRR mode, proper vblank/pageflip timestamps can only be computed
after the display scanout position has left front-porch. Therefore
delay calls to drm_crtc_handle_vblank(), and thereby calls to
drm_update_vblank_count() and pageflip event delivery, to after the
end of front-porch when in VRR mode.

We add a new vupdate irq, which triggers at the end of the vupdate
interval, ie. at the end of vblank, and calls the core vblank handler
function. The new irq handler is not executed in standard non-VRR
mode, so vblank handling for fixed refresh rate mode is identical
to the past implementation.

v2: Implement feedback by Nicholas and Paul Menzel.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

For throttling to work correctly, we always need a baseline vblank
count last_flip_vblank that increments at start of front-porch.

This is the case for drm_crtc_vblank_count() in non-VRR mode, where
the vblank irq fires at start of front-porch and triggers DRM core
vblank handling, but it is no longer the case in VRR mode, where
core vblank handling is done later, after end of front-porch.

Therefore drm_crtc_vblank_count() is no longer useful for this.
We also can't use drm_crtc_accurate_vblank_count(), as that would
screw up vblank timestamps in VRR mode when called in front-porch.

To solve this, use the cooked hardware vblank counter returned by
amdgpu_get_vblank_counter_kms() instead, as that one is cooked to
always increment at start of front-porch, independent of when
vblank related irq's fire.

This patch allows vblank irq handling to happen anywhere within
vblank of even after it, without a negative impact on flip
throttling, so followup patches can shift the vblank core
handling trigger point wherever they need it.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

During VRR mode we can not allow vblank irq dis-/enable
transitions, as an enable after a disable can happen at
an arbitrary time during the video refresh cycle, e.g.,
with a high likelyhood inside vblank front-porch. An
enable during front-porch would cause vblank timestamp
updates/calculations which are completely bogus, given
the code can't know when the vblank will end as long
as we are in front-porch with no page flip completed.

Hold a permanent vblank reference on the crtc while
in active VRR mode to prevent a vblank disable, and
drop the reference again when switching back to fixed
refresh rate non-VRR mode.

v2: Make sure transition is also handled if vrr is
    disabled and stream gets disabled in the same
    atomic commit by moving the call to the transition
    function outside of plane commit.
    Suggested by Nicholas.

v3: Trivial rebase onto previous patch.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

We need the VRR active/inactive state info earlier in
the commit sequence, so VRR related setup functions like
amdgpu_dm_handle_vrr_transition() know the final VRR state
when they need to do their hw setup work.

Split update_freesync_state_on_stream() into an early part,
that can run at the beginning of commit tail before the
vrr transition handling, and a late part that must run after
vrr transition handling inside the commit planes code for
enabled crtc's.

Suggested by Nicholas Kazlauskas.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
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]
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]
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>

[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]
The DRM overlay planes DM exposes support RGBA formats but are currently
forced as fully opaque over whatever they overlay.

[How]
Expose DRM blending mode and alpha properties to userspace.

The overlays exposed support per-pixel pre-multiplied alpha along with
global plane opacity.
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NHarry Wentland <Harry.Wentland@amd.com>
Acked-by: NLeo Li <sunpeng.li@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Can happen on ASICs with 6 planes, but this isn't a bug since we haven't
written outside the array.

[How]
Use <= instead of <.

Cc: Leo Li <sunpeng.li@amd.com>
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reported-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Tested-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>