linux-stable.git/drivers/gpu/drm/amd, branch v5.3.3

drm/amd/display: readd -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines

2019-10-01T06:24:45+00:00

commit 0f0727d971f6fdf8f1077180d495ddb9928f0c8b upstream.

arch/x86/Makefile disables SSE and SSE2 for the whole kernel.  The
AMDGPU drivers modified in this patch re-enable SSE but not SSE2.  Turn
on SSE2 to support emitting double precision floating point instructions
rather than calls to non-existent (usually available from gcc_s or
compiler_rt) floating point helper routines for Clang.

This was originally landed in:
commit 10117450735c ("drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines")
but reverted in:
commit 193392ed9f69 ("Revert "drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines"")
due to bugreports from GCC builds. Add guards to only do so for Clang.

Link: https://bugs.freedesktop.org/show_bug.cgi?id=109487
Link: https://github.com/ClangBuiltLinux/linux/issues/327

Suggested-by: Sedat Dilek 
Suggested-by: Sami Tolvanen 
Signed-off-by: Nick Desaulniers 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Don't replace the dc_state for fast updates

2019-10-01T06:24:44+00:00

commit bd200d190f45b62c006d1ad0a63eeffd87db7a47 upstream.

[Why]
DRM private objects have no hw_done/flip_done fencing mechanism on their
own and cannot be used to sequence commits accordingly.

When issuing commits that don't touch the same set of hardware resources
like page-flips on different CRTCs we can run into the issue below
because of this:

1. Client requests non-blocking Commit #1, has a new dc_state #1,
state is swapped, commit tail is deferred to work queue

2. Client requests non-blocking Commit #2, has a new dc_state #2,
state is swapped, commit tail is deferred to work queue

3. Commit #2 work starts, commit tail finishes,
atomic state is cleared, dc_state #1 is freed

4. Commit #1 work starts,
commit tail encounters null pointer deref on dc_state #1

In order to change the DC state as in the private object we need to
ensure that we wait for all outstanding commits to finish and that
any other pending commits must wait for the current one to finish as
well.

We do this for MEDIUM and FULL updates. But not for FAST updates, nor
would we want to since it would cause stuttering from the delays.

FAST updates that go through dm_determine_update_type_for_commit always
create a new dc_state and lock the DRM private object if there are
any changed planes.

We need the old state to validate, but we don't actually need the new
state here.

[How]
If the commit isn't a full update then the use after free can be
resolved by simply discarding the new state entirely and retaining
the existing one instead.

With this change the sequence above can be reexamined. Commit #2 will
still free Commit #1's reference, but before this happens we actually
added an additional reference as part of Commit #2.

If an update comes in during this that needs to change the dc_state
it will need to wait on Commit #1 and Commit #2 to finish. Then it'll
swap the state, finish the work in commit tail and drop the last
reference on Commit #2's dc_state.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204181
Fixes: 004b3938e637 ("drm/amd/display: Check scaling info when determing update type")

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

drm/amd/display: Skip determining update type for async updates

2019-10-01T06:24:44+00:00

commit 43d10d30df156f7834fa91aecb69614fefc8bb0a upstream.

[Why]
By passing through the dm_determine_update_type_for_commit for atomic
commits that can be done asynchronously we are incurring a
performance penalty by locking access to the global private object
and holding that access until the end of the programming sequence.

This is also allocating a new large dc_state on every access in addition
to retaining all the references on each stream and plane until the end
of the programming sequence.

[How]
Shift the determination for async update before validation. Return early
if it's going to be an async update.

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

drm/amd/display: Allow cursor async updates for framebuffer swaps

2019-10-01T06:24:44+00:00

commit e16e37efb4c9eb7bcb9dab756c975040c5257e98 upstream.

[Why]
We previously allowed framebuffer swaps as async updates for cursor
planes but had to disable them due to a bug in DRM with async update
handling and incorrect ref counting. The check to block framebuffer
swaps has been added to DRM for a while now, so this check is redundant.

The real fix that allows this to properly in DRM has also finally been
merged and is getting backported into stable branches, so dropping
this now seems to be the right time to do so.

[How]
Drop the redundant check for old_fb != new_fb.

With the proper fix in DRM, this should also fix some cursor stuttering
issues with xf86-video-amdgpu since it double buffers the cursor.

IGT tests that swap framebuffers (-varying-size for example) should
also pass again.

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

drm/amdgpu: fix GFXOFF on Picasso and Raven2

2019-08-27T17:25:20+00:00

For picasso(adev->pdev->device == 0x15d8)&raven2(adev->rev_id >= 0x8),
firmware is sufficient to support gfxoff.
In commit 98f58ada2d37e, for picasso&raven2,
return directly and cause gfxoff disabled.

Fixes: 98f58ada2d37 ("drm/amdgpu/gfx9: update pg_flags after determining if gfx off is possible")
Reviewed-by: Huang Rui 
Reviewed-by: Alex Deucher 
Signed-off-by: Aaron Liu 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org

drm/amdgpu: Add APTX quirk for Dell Latitude 5495

2019-08-27T17:24:40+00:00

Needs ATPX rather than _PR3 to really turn off the dGPU. This can save
~5W when dGPU is runtime-suspended.

Signed-off-by: Kai-Heng Feng 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org

drm/amd/powerplay: correct Vega20 dpm level related settings

2019-08-27T17:23:40+00:00

Correct the settings for auto mode and skip the unnecessary
settings for dcefclk and fclk.

Signed-off-by: Evan Quan 
Acked-by: Alex Deucher 
Signed-off-by: Alex Deucher

drm/powerplay: Fix Vega20 power reading again

2019-08-26T21:20:32+00:00

For the 40.46 SMU release, they changed CurrSocketPower to
AverageSocketPower, but this was changed back in 40.47 so just check if
it's 40.46 and make the appropriate change

Tested with 40.45, 40.46 and 40.47 successfully

Signed-off-by: Kent Russell 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher

drm/powerplay: Fix Vega20 Average Power value v4

2019-08-26T21:20:02+00:00

The SMU changed reading from CurrSocketPower to AverageSocketPower, so
reflect this accordingly. This fixes the issue where Average Power
Consumption was being reported as 0 from SMU 40.46-onward

v2: Fixed headline prefix
v3: Add check for SMU version for proper compatibility
v4: Style fix

Signed-off-by: Kent Russell 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher

drm/amdgpu: fix dma_fence_wait without reference

2019-08-26T20:33:36+00:00

We need to grab a reference to the fence we wait for.

Signed-off-by: Christian König 
Reviewed-by: Chunming Zhou 
Signed-off-by: Alex Deucher