linux.git/drivers/gpu/drm/amd/display/amdgpu_dm, branch v5.7-rc2

drm/amdgpu/display: fix warning when compiling without debugfs

2020-04-08T21:53:11+00:00

fixes unused variable warning.

Reported-by: Eric Biggers 
Acked-by: Christian König 
Reviewed-by: Mikita Lipski 
Signed-off-by: Alex Deucher

drm/amd/display: Make cursor source translation adjustment optional

2020-04-07T18:20:45+00:00

[Why]
In some usecases, like tiled display, the stream and plane configuration
can be setup in a way where the caller expects DAL to perform the
clipping, eg:

P0:
src_rect(0, 0, w, h)
dst_rect(0, 0, w, h)

P1:
src_rect(w, 0, w, h)
dst_rect(0, 0, w, h)

Cursor is enabled on both streams with the same position.

This can result in double cursor on tiled display, even though this
behavior is technically correct from the DC interface point of view.

We need a mechanism to control this dynamically.

[How]
This is something that should live in the DM layer based on detection
of the specified configuration but it's not something that we really
have enough information to deal with today.

Add a flag to the cursor position state that specifies whether we
want DC to do the translation or not and make it opt-in and let
the DM decide when to do it.

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Tony Cheng 
Acked-by: Rodrigo Siqueira 
Signed-off-by: Alex Deucher

drm/amd/display: Fix incorrect cursor pos on scaled primary plane

2020-04-07T18:20:45+00:00

[Why]
Cursor pos is correctly adjusted from DC side for source rect offset
on DCN ASIC, but only on the overlay.

This is because DM places offsets the cursor for primary planes only
to workaround missing code in DCE for the adjustment we're now correctly
doing in DC for DCN ASIC.

[How]
Drop the adjustment for source rect from the DM side of things and put
the code where it actually belongs - in DC on the pipe level.

This matches what we do for DCN now.

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Zhan Liu 
Acked-by: Rodrigo Siqueira 
Signed-off-by: Alex Deucher

drm/amd/display: Avoid create MST prop after registration

2020-04-07T18:10:24+00:00

[Why]
Prop are created at boot stage, and not allowed to create new prop
after device registration.

[How]
Reuse the connector property from SST if exist.

Signed-off-by: Jerry (Fangzhi) Zuo 
Reviewed-by: Hersen Wu 
Acked-by: Rodrigo Siqueira 
Signed-off-by: Alex Deucher

drm/amd/display: increase HDCP authentication delay

2020-03-31T16:44:29+00:00

[Why]
Some displays have an issue where the hdcp chips are initialized after the
display has already lit up. This means we can sometimes authentication too early
and cause authentication failures.

This happens when HDCP is enabled and the display is power cycled. Normally we
will authenticate 2 seconds after the display is lit, but some displays need a
bit more time.

[How]
Increase delay to 3 second before we start authentication.

Signed-off-by: Bhawanpreet Lakha 
Reviewed-by: Nicholas Kazlauskas 
Signed-off-by: Alex Deucher

drm/amd/display: Correctly cancel future watchdog and callback events

2020-03-31T16:44:29+00:00

[Why]
-We need to cancel future callbacks/watchdogs events when a callback/watchdog event happens

[How]
-fix typo in event_callback()
	-cancel callback, not watchdog
-cancel watchdog events in event_watchdog_timer().

Signed-off-by: Bhawanpreet Lakha 
Reviewed-by: Nicholas Kazlauskas 
Signed-off-by: Alex Deucher

drm/amd/display: Don't try hdcp1.4 when content_type is set to type1

2020-03-31T16:44:29+00:00

[Why]
When content type property is set to 1. We should enable hdcp2.2 and if we cant
then stop. Currently the way it works in DC is that if we fail hdcp2, we will
try hdcp1 after.

[How]
Use link config to force disable hdcp1.4 when type1 is set.

Signed-off-by: Bhawanpreet Lakha 
Reviewed-by: Nicholas Kazlauskas 
Signed-off-by: Alex Deucher

drm/amd/display: Enable BT2020 in COLOR_ENCODING property

2020-03-31T16:26:15+00:00

[Why]
BT2020 is not supported in COLOR_ENCODING property of planes.  Only
BT601 and BT709 was available.

[How]
Allow BT2020 as legit value in setting COLOR_ENCODING property.

Signed-off-by: Stylon Wang 
Reviewed-by: Nicholas Kazlauskas 
Acked-by: Rodrigo Siqueira 
Signed-off-by: Alex Deucher

drm/amd/display: Support P010 pixel format

2020-03-31T16:26:14+00:00

[Why]
P010 pixel format is not declared as supported in DRM and DM.

[How]
Add P010 format to the support list presented to DRM and checked in DM

Signed-off-by: Stylon Wang 
Reviewed-by: Nicholas Kazlauskas 
Acked-by: Rodrigo Siqueira 
Signed-off-by: Alex Deucher

drm/amd/display: Fix pageflip event race condition for DCN.

2020-03-25T21:00:11+00:00

Commit '16f17eda8bad ("drm/amd/display: Send vblank and user
events at vsartup for DCN")' introduces a new way of pageflip
completion handling for DCN, and some trouble.

The current implementation introduces a race condition, which
can cause pageflip completion events to be sent out one vblank
too early, thereby confusing userspace and causing flicker:

prepare_flip_isr():

1. Pageflip programming takes the ddev->event_lock.
2. Sets acrtc->pflip_status == AMDGPU_FLIP_SUBMITTED
3. Releases ddev->event_lock.

--> Deadline for surface address regs double-buffering passes on
    target pipe.

4. dc_commit_updates_for_stream() MMIO programs the new pageflip
   into hw, but too late for current vblank.

=> pflip_status == AMDGPU_FLIP_SUBMITTED, but flip won't complete
   in current vblank due to missing the double-buffering deadline
   by a tiny bit.

5. VSTARTUP trigger point in vblank is reached, VSTARTUP irq fires,
   dm_dcn_crtc_high_irq() gets called.

6. Detects pflip_status == AMDGPU_FLIP_SUBMITTED and assumes the
   pageflip has been completed/will complete in this vblank and
   sends out pageflip completion event to userspace and resets
   pflip_status = AMDGPU_FLIP_NONE.

=> Flip completion event sent out one vblank too early.

This behaviour has been observed during my testing with measurement
hardware a couple of time.

The commit message says that the extra flip event code was added to
dm_dcn_crtc_high_irq() to prevent missing to send out pageflip events
in case the pflip irq doesn't fire, because the "DCH HUBP" component
is clock gated and doesn't fire pflip irqs in that state. Also that
this clock gating may happen if no planes are active. This suggests
that the problem addressed by that commit can't happen if planes
are active.

The proposed solution is therefore to only execute the extra pflip
completion code iff the count of active planes is zero and otherwise
leave pflip completion handling to the pflip irq handler, for a
more race-free experience.

Note that i don't know if this fixes the problem the original commit
tried to address, as i don't know what the test scenario was. It
does fix the observed too early pageflip events though and points
out the problem introduced.

Fixes: 16f17eda8bad ("drm/amd/display: Send vblank and user events at vsartup for DCN")
Reviewed-by: Nicholas Kazlauskas 
Signed-off-by: Mario Kleiner 
Signed-off-by: Alex Deucher