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

drm/amd/display: Use long for signed error code checks in commit planes

2019-05-06T14:36:48+00:00

[Why]

The type of 'r' is uint32_t and the return codes for both:

- reservation_object_wait_timeout_rcu
- amdgpu_bo_reserve

...are signed. While it works for the latter since the check is
done on != 0 it doesn't work for the former since we check <= 0.

[How]

Make 'r' a long in commit planes so we're not doing any unsigned/signed
conversion here in the first place.

v2: use long instead of int (Christian)

Reported-by: Dan Carpenter 
Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher

Merge branch 'drm-next-5.2' of git://people.freedesktop.org/~agd5f/linux into drm-next

2019-05-03T00:31:07+00:00

- SR-IOV fixes
- Raven flickering fix
- Misc spelling fixes
- Vega20 power fixes
- Freesync improvements
- DC fixes

Signed-off-by: Dave Airlie 
From: Alex Deucher 
Link: https://patchwork.freedesktop.org/patch/msgid/20190502193020.3562-1-alexander.deucher@amd.com

drm/amd/display: Compensate for pre-DCE12 BTR-VRR hw limitations. (v3)

2019-04-29T19:59:44+00:00

Pre-DCE12 needs special treatment for BTR / low framerate
compensation for more stable behaviour:

According to comments in the code and some testing on DCE-8
and DCE-11, DCE-11 and earlier only apply VTOTAL_MIN/MAX
programming with a lag of one frame, so the special BTR hw
programming for intermediate fixed duration frames must be
done inside the current frame at flip submission in atomic
commit tail, ie. one vblank earlier, and the fixed refresh
intermediate frame mode must be also terminated one vblank
earlier on pre-DCE12 display engines.

To achieve proper termination on < DCE-12 shift the point
when the switch-back from fixed vblank duration to variable
vblank duration happens from the start of VBLANK (vblank irq,
as done on DCE-12+) to back-porch or end of VBLANK (handled
by vupdate irq handler). We must leave the switch-back code
inside VBLANK irq for DCE12+, as before.

Doing this, we get much better behaviour of BTR for up-sweeps,
ie. going from short to long frame durations (~high to low fps)
and for constant framerate flips, as tested on DCE-8 and
DCE-11. Behaviour is still not quite as good as on DCN-1
though.

On down-sweeps, going from long to short frame durations
(low fps to high fps) < DCE-12 is a little bit improved,
although by far not as much as for up-sweeps and constant
fps.

v2: Fix some wrong locking, as pointed out by Nicholas.
v3: Simplify if-condition in vupdate-irq - nit by Nicholas.
Signed-off-by: Mario Kleiner 
Reviewed-by: Nicholas Kazlauskas 
Signed-off-by: Alex Deucher

drm/amd/display: Expose DRM_FORMAT_RGB565 on overlay planes

2019-04-29T19:59:29+00:00

RGB565 support isn't restricted to just the primary plane in DC, so
also expose support for it on overlays.

Signed-off-by: Nicholas Kazlauskas 
Acked-by: Alex Deucher 
Reviewed-by: David Francis 
Signed-off-by: Alex Deucher

drm/amd/display: Do VRR transition before enable_crc_interrupts

2019-04-29T19:59:20+00:00

[Why]
Originally we did the amdgpu_dm_handle_vrr_transition call before
interrupts were enabled. After the interrupt toggling logic was
moved around for support enabling CRTCs with no primary planes
active this was no longer being called in the case where there
wasn't a modeset.

This fixes failures in igt@kms_vrr@* with error
"Timed out: Waiting for vblank event".

[How]
Shift them back into the loop that always ran before interrupts were
enabled.

Pull out the logic that updated VRR state into the same loop since
there's no reason these need to be split.

In the case where we're going from VRR off, no planes to VRR on, some
active planes we'll still be covered for having the VRR vupdate
handler enabled - vblank will be re-enabled at this point, it will
see that VRR is active and set the vupdate interrupt on there.

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: David Francis 
Acked-by: Leo Li 
Signed-off-by: Alex Deucher

drm/amd/display: Add power down display on boot flag

2019-04-29T19:58:53+00:00

[Why]

Due to the generic introduction of seamless boot, the display is no
longer blanked upon boot. However, this causes corruption on some
systems that does not lock the memory in the non-secure boot case,
resulting in brief corruption on boot due to garbage being written into
the frame buffer.

[How]
Add a flag, read during DC init, to determine whether display should be
blanked on boot. Default to true.

Signed-off-by: Thomas Lim 
Reviewed-by: Aric Cyr 
Acked-by: Anthony Koo 
Acked-by: Leo Li 
Signed-off-by: Alex Deucher

drm/amd/display: Allow commits with no planes active

2019-04-29T19:58:38+00:00

[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: Nicholas Kazlauskas 
Reviewed-by: David Francis 
Acked-by: Leo Li 
Signed-off-by: Alex Deucher

drm/amd/display: Split enabling CRTC interrupts into two passes

2019-04-29T19:58:30+00:00

[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: Nicholas Kazlauskas 
Reviewed-by: David Francis 
Acked-by: Leo Li 
Signed-off-by: Alex Deucher

drm/amd/display: Fix CRC vblank refs when changing interrupts

2019-04-29T19:58:23+00:00

[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: Nicholas Kazlauskas 
Reviewed-by: David Francis 
Acked-by: Leo Li 
Signed-off-by: Alex Deucher

drm/amd/display: Disable cursors before disabling planes

2019-04-29T19:58:16+00:00

[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: Nicholas Kazlauskas 
Reviewed-by: David Francis 
Acked-by: Leo Li 
Signed-off-by: Alex Deucher