linux-stable.git/drivers/gpu/drm/amd/display/amdgpu_dm, branch v5.2.20

drm/amd/display: Restore backlight brightness after system resume

2019-10-05T11:14:16+00:00

commit bb264220d9316f6bd7c1fd84b8da398c93912931 upstream.

Laptops with AMD APU doesn't restore display backlight brightness after
system resume.

This issue started when DC was introduced.

Let's use BL_CORE_SUSPENDRESUME so the backlight core calls
update_status callback after system resume to restore the backlight
level.

Tested on Dell Inspiron 3180 (Stoney Ridge) and Dell Latitude 5495
(Raven Ridge).

Cc: 
Signed-off-by: Kai-Heng Feng 
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-01T07:01:35+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-01T07:01:35+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-01T07:01:35+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/amd/display: Always allocate initial connector state state

2019-07-31T05:24:38+00:00

[ Upstream commit f04bee34d6e35df26cbb2d65e801adfd0d8fe20d ]

[Why]
Unlike our regular connectors, MST connectors don't start off with
an initial connector state. This causes a NULL pointer dereference to
occur when attaching the bpc property since it tries to modify the
connector state.

We need an initial connector state on the connector to avoid the crash.

[How]
Use our reset helper to allocate an initial state and reset the values
to their defaults. We were already doing this before, just not for
MST connectors.

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Leo Li 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: Reset planes for color management changes

2019-07-31T05:24:35+00:00

[ Upstream commit 7316c4ad299663a16ca9ce13e5e817b4ca760809 ]

[Why]
For commits with allow_modeset=false and CRTC degamma changes the planes
aren't reset. This results in incorrect rendering.

[How]
Reset the planes when color management has changed on the CRTC.
Technically this will include regamma changes as well, but it doesn't
really after legacy userspace since those commit with
allow_modeset=true.

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Harry Wentland 
Acked-by: Leo Li 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: Fill plane attrs only for valid pxl format

2019-07-31T05:24:32+00:00

[ Upstream commit 1894478ad1f8fd7366edc5cee49ee9caea0e3d52 ]

[Why]
In fill_plane_buffer_attributes() we calculate chroma/luma
assuming that the surface_pixel_format is always valid.
If it's not the case, there's a risk of divide by zero error.

[How]
Check if format valid before calculating pixel format attributes

Signed-off-by: Roman Li 
Reviewed-by: David Francis 
Acked-by: Bhawanpreet Lakha 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: Disable cursor when offscreen in negative direction

2019-07-31T05:24:32+00:00

[ Upstream commit e371e19c10a264bd72c2ff1d21e2167b994710d1 ]

[Why]
When x or y is negative we set the x and y values to 0 and compensate
with a positive cursor hotspot in DM since DC expects positive cursor
values.

When x or y is less than or equal to the maximum cursor width or height
the cursor hotspot is clamped so the hotspot doesn't exceed the
cursor size:

if (x < 0) {
        xorigin = min(-x, amdgpu_crtc->max_cursor_width - 1);
        x = 0;
}

if (y < 0) {
        yorigin = min(-y, amdgpu_crtc->max_cursor_height - 1);
        y = 0;
}

This incorrectly forces the cursor to be at least 1 pixel on the screen
in either direction when x or y is sufficiently negative.

[How]
Just disable the cursor when it goes far enough off the screen in one
of these directions.

This fixes kms_cursor_crc@cursor-256x256-offscreen.

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Sun peng Li 
Acked-by: Bhawanpreet Lakha 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd: fix fb references in async update

2019-06-04T08:13:17+00:00

Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.

Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
fb and put the old fb) is not required, as it's taken care by
drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane().

Cc:  # v4.20+
Fixes: 674e78acae0d ("drm/amd/display: Add fast path for cursor plane updates")
Suggested-by: Boris Brezillon 
Signed-off-by: Helen Koike 
Reviewed-by: Nicholas Kazlauskas 
Signed-off-by: Boris Brezillon 
Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-3-helen.koike@collabora.com

drm/amd/display: Don't load DMCU for Raven 1 (v2)

2019-05-24T15:16:36+00:00

[WHY]
Some early Raven boards had a bad SBIOS that doesn't play nicely with
the DMCU FW. We thought the issues were fixed by ignoring errors on DMCU
load but that doesn't seem to be the case. We've still seen reports of
users unable to boot their systems at all.

[HOW]
Disable DMCU load on Raven 1. Only load it for Raven 2 and Picasso.

v2: Fix ifdef (Alex)

Signed-off-by: Harry Wentland 
Reviewed-by: Nicholas Kazlauskas 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org