[Why]
The wait_for_vblank boolean in commit_tail was passed by reference
into each stream commit, and if that commit was an asynchronous
flip, it would disable vblank waits on all subsequent flips.
This made the behaviour depend on crtc order in a non-intuitive way,
although since the asynchronous pageflip flag is only used by the
legacy IOCTLs at the moment it is never an issue
[How]
Find wait_for_vblank before doing any stream commits
Signed-off-by: David Francis <David.Francis@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
In VRR mode, keep track of the vblank count of the last
completed pageflip in amdgpu_crtc->last_flip_vblank, as
recorded in the pageflip completion handler after each
completed flip.
Use that count to prevent mmio programming a new pageflip
within the same vblank in which the last pageflip completed,
iow. to throttle pageflips to at most one flip per video
frame, while at the same time allowing to request a flip
not only before start of vblank, but also anywhere within
vblank.
The old logic did the same, and made sense for regular fixed
refresh rate flipping, but in vrr mode it prevents requesting
a flip anywhere inside the possibly huge vblank, thereby
reducing framerate in vrr mode instead of improving it, by
delaying a slightly delayed flip requests up to a maximum
vblank duration + 1 scanout duration. This would limit VRR
usefulness to only help applications with a very high GPU
demand, which can submit the flip request before start of
vblank, but then have to wait long for fences to complete.
With this method a flip can be both requested and - after
fences have completed - executed, ie. it doesn't matter if
the request (amdgpu_dm_do_flip()) gets delayed until deep
into the extended vblank due to cpu execution delays. This
also allows clients which want to regulate framerate within
the vrr range a much more fine-grained control of flip timing,
a feature that might be useful for video playback, and is
very useful for neuroscience/vision research applications.
In regular non-VRR mode, retain the old flip submission
behavior. This to keep flip scheduling for fullscreen X11/GLX
OpenGL clients intact, if they use the GLX_OML_sync_control
extensions glXSwapBufferMscOML(, ..., target_msc,...) function
with a specific target_msc target vblank count.
glXSwapBuffersMscOML() or DRI3/Present PresentPixmap() will
not flip at the proper target_msc for a non-zero target_msc
if VRR mode is active with this patch. They'd often flip one
frame too early. However, this limitation should not matter
much in VRR mode, as scheduling based on vblank counts is
pretty futile/unusable under variable refresh duration
anyway, so no real extra harm is done.
According to some testing already done with this patch by
Nicholas on top of my tests, IGT tests didn't report any
problems. If fixes stuttering and flickering when flipping
at rates below the minimum vrr refresh rate.
Fixes: bb47de7366 ("drm/amdgpu: Set FreeSync state using drm VRR
properties")
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: <stable@vger.kernel.org>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Michel Dänzer <michel@daenzer.net>
Tested-by: Bruno Filipe <bmilreu@gmail.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fixes for 5.1:
amdgpu:
- Fix missing fw declaration after dropping old CI DPM code
- Fix debugfs access to registers beyond the MMIO bar size
- Fix context priority handling
- Add missing license on some new files
- Various cleanups and bug fixes
radeon:
- Fix missing break in CS parser for evergreen
- Various cleanups and bug fixes
sched:
- Fix entities with 0 run queues
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190221214134.3308-1-alexander.deucher@amd.com
[Why]
Cursor updates used to happen after vblank/flip/stream updates before
the stream update refactor. They now happen before stream updates
which means that they're not going to be synced with fb changes
and that they're going to programmed for pipes that we're disabling
within the same commit.
[How]
Move them after stream updates.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: David Francis <David.Francis@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Whenever a stream or plane is added or removed from the context the
pointer will change from old to new. We set lock and validation
needed in these cases. But not all of these cases match update_type
from dm_determine_update_type_for_commit - an example being overlay
plane updates.
There are warnings for a few of these cases that should be fixed.
[How]
We can closer align to DC (and lock_and_validation_needed) by
comparing stream and plane pointers.
Since the old stream/old plane state is never freed until sometime
after the commit tail work finishes we are guaranteed to never get
back the same block of memory when we remove and create a stream or
plane state in the same commit.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
This format isn't supported in DC and some IGT tests fail since we
expose support for it.
[How]
Remove it.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
If a commit updates an overlay plane via the legacy plane IOCTL
then the only plane in the state will be the overlay plane.
Overlay planes need to be added first to the DC context, but in the
scenario above the plane will be added last. This will result in wrong
z-order during rendering.
[How]
If any non-cursor plane has been updated then the rest of the
non-cursor planes should be added to the CRTC state.
The cursor plane doesn't need to be included for stream updates and
locking it will cause performance issues. It should be ignored.
DC requires that the surface count passed during stream updates
be the number of surfaces currently on the stream to enable fast
updates. This previously wasn't the case without this patch, so this
also allows this optimization to occur.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
Acked-by: Tony Cheng <Tony.Cheng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-----BEGIN PGP SIGNATURE-----
iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAlxqHJYeHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGWl8H/jPI4EipzD2GbnjZ
GaFpMBBjcXBaVmoA+Y69so+7BHx1Ql+5GQtqbK0RHJRb9qEPLw3FBhHNjM/N8Sgf
nSrK+GnBZp9s+k/NR/Yf2RacUR3jhz+Q9JEoQd3u9bFUeQyvE8Rf3vgtoBBwFOfz
+t7N1memYVF3asLGWB4e4sP1YVMGfseTQpSPojvM30YWM86Bv+QtSx1AGgHczQIM
kMKealR8ZPelN6JAXgLhQ5opDojBrE4YKB98pwsMDI6abz0Tz2JLFEUTTxsv5XNN
o/Iz+XDoylskEyxN2unNWfHx7Swkvoklog8J/hDg5XlTvipL/WkT66PHBgcGMNvj
BW9GgU8=
=ZizU
-----END PGP SIGNATURE-----
Merge v5.0-rc7 into drm-next
Backmerging for nouveau and imx that needed some fixes for next pulls.
Signed-off-by: Dave Airlie <airlied@redhat.com>
When ring hang happens amdgpu_dm_commit_planes during flip is holding
the BO reserved and then stack waiting for fences to signal in
reservation_object_wait_timeout_rcu (which won't signal because there
was a hnag). Then when we try to shutdown display block during reset
recovery from drm_atomic_helper_suspend we also try to reserve the BO
from dm_plane_helper_cleanup_fb ending in deadlock.
Also remove useless WARN_ON
Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
There are opt1c lock warnings and CRTC read timeouts when running the
"igt@kms_plane@plane-position-hole-dpms-pipe-*" tests. These are
caused by trying to reprogram planes that are not in the current
context.
DPMS off removes the stream from the context. In this case:
new_crtc_state->active_changed = true
new_crtc_state->mode_changed = false
The planes are reprogrammed before the stream is removed from the
context because stream_state->mode_changed = false.
For DPMS adds the stream and planes back to the context:
new_crtc_state->active_changed = true
new_crtc_state->mode_changed = false
The planes are also reprogrammed here before the stream is added to the
context because stream_state->mode_changed = true. They were not
previously in the current context so warnings occur here.
[How]
Set stream_state->mode_changed = true when
new_crtc_state->active_changed = true too.
This prevents reprogramming before the context is applied in DC. The
programming will be done after the context is applied.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Acked-by: Tony Cheng <Tony.Cheng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
It fixes the failure to create stream for sink in the scenario
when hotplug SST and MST in sequence, and disconnect MST.
[How]
Add the fake sink back after the majority of MST rework is done.
Signed-off-by: Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Acked-by: Tony Cheng <Tony.Cheng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Setting monitor refresh rate below freesync range would cause the
monitor to go blank indefinitely with freesync enabled
[How]
Set vrr_supported and ignore_msa_timing_param according to whether
the refresh rate is above or below the minimum freesync frequency.
Signed-off-by: Ilya Bakoulin <Ilya.Bakoulin@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
This provides little debug value and creates a lot of dmesg noise.
[How]
Remove it.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: David Francis <David.Francis@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
The stream_update struct is left unitialized but DC will access
its fields. This usually results in global state validation occur
during any atomic commit with state->allow_modeset = true.
[How]
Initialize the struct to zero for every stream we check.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: David Francis <David.Francis@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
The indenting for this function is a few levels too deep and can be
simplified a fair bit. This patch is in preparation for functional
changes that fix update type determination to occur less frequently
and more accurately.
[How]
Place checks early and exit/continue when possible. This isn't
a functional change.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: David Francis <David.Francis@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
We were always passing the first surface on the stream status for
flip updates when we should be using the surface associated with
the plane.
[How]
Use the dc_plane_state from the plane that's being updated.
FreeSync should also only keep track of updates from the primary
plane, so the check needed to be updated.
The acrtc->stream state doesn't need to be checked for NULL before
updating FreeSync either since there needs to be a stream to be
inside this function as a prerequisite.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: David Francis <David.Francis@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Most surface updates weren't propagated onto the surface during
dc_commit_updates_for_stream. This makes it more difficult for DC to
determine the actual surface update type required.
[How]
Use copy_surface_update_to_plane to propagate the changes. The FreeSync
surface timing information update for BTR has been moved out of
amdgpu_dm.c into this function as well.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
When CONFIG_DEBUG_FS isn't defined then amdgpu_dm_crtc_set_crc_source
is NULL. This causes a compilation error since it's being called
unconditionally.
[How]
Guard the call based on CONFIG_DEBUG_FS - CRC capture isn't supported
without this.
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Fixes: 43a6a02eb3 ("drm/amd/display: Re-enable CRC capture following modeset")
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Clang warns:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:2314:38:
warning: suggest braces around initialization of subobject
[-Wmissing-braces]
struct dc_surface_dcc_cap output = {0};
^
{}
Previous efforts to fix this type of warning by adding or removing
braces have been met with some pushback in favor of using memset [1][2].
Do that here, mirroring commit 05794eff1a ("drm/amdgpu/gmc: fix
compiler errors [-Werror,-Wmissing-braces] (V2)") in this tree.
[1]: https://lore.kernel.org/lkml/022e41c0-8465-dc7a-a45c-64187ecd9684@amd.com/
[2]: https://lore.kernel.org/lkml/20181128.215241.702406654469517539.davem@davemloft.net/
Fixes: 7df7e505e8 ("drm/amd/display: Set requested plane state DCC params for GFX9")
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Clang warns:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5089:60:
warning: suggest braces around initialization of subobject
[-Wmissing-braces]
struct dc_surface_update dummy_updates[MAX_SURFACES] = { 0 };
^
{}
Previous efforts to fix this type of warning by adding or removing
braces have been met with some pushback in favor of using memset [1][2].
Do that here, mirroring commit 05794eff1a ("drm/amdgpu/gmc: fix
compiler errors [-Werror,-Wmissing-braces] (V2)") in this tree.
[1]: https://lore.kernel.org/lkml/022e41c0-8465-dc7a-a45c-64187ecd9684@amd.com/
[2]: https://lore.kernel.org/lkml/20181128.215241.702406654469517539.davem@davemloft.net/
Fixes: 02d6a6fcdf ("drm/amd/display: Simplify underscan and ABM commit")
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
eDP was missing in the checks for supported VRR connectors.
[How]
Attach the properties for eDP connectors too.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202449
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
The flip and full structures were allocated but never freed.
[How]
Free them at the end of the function. There's a small behavioral
change here with the function returning early if the allocation fails
but we wouldn't should be doing anything in that case anyway.
Fixes: c00e0cc0fdc0 ("drm/amd/display: Call into DC once per multiplane flip")
Fixes: ea39594e0855 ("drm/amd/display: Perform plane updates only when needed")
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
During any modeset the CRTC stream is removed and a new stream is added.
This new stream doesn't carry over CRC capture state if it was
previously set.
[How]
Re-program the stream for CRC capture. The existing DRM callback can
be re-used here for the most part - the only modification needed is
additional locking now that it's called from within commit tail.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
In order to read CRC events when CRC capture is enabled the vblank
interrput handler needs to be running for the CRTC. The handler is
enabled while there is an active vblank reference.
When running IGT tests there will often be no active vblank reference
but the test expects to read a CRC value. This is valid usage (and
works on i915 since they have a CRC interrupt handler) so the reference
to the vblank should be grabbed while capture is active.
This issue was found running:
igt@kms_plane_multiple@atomic-pipe-b-tiling-none
The pipe-b is the only one in the initial commit and was not previously
active so no vblank reference is grabbed. The vblank interrupt is
not enabled and the test times out.
[How]
Keep a reference to the vblank as long as CRC capture is enabled.
If userspace never explicitly disables it then the reference is
also dropped when removing the CRTC from the context (stream = NULL).
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
We were assuming that any commit with allow_modeset == false
was a pageflip. This was against drm intention and only
worked by sheer luck
[How]
A pageflip is the change from one framebuffer to another
Signed-off-by: David Francis <David.Francis@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Our old logic: if pageflip, update freesync and plane address.
Otherwise, update everything.
This over-updated on non-pageflip cases, and it failed to
update if pageflip and non-pageflip changes occurred on
the same commit
[How]
Update flip_addrs on pageflips.
Update scaling_info when it changes.
Update color fields on color changes.
Updates plane_info always because we don't have a good way of
knowing when it needs to be updated.
Unfortunately, this means that every stream commit involves two
calls into DC. In particular, on pageflips there is a second,
pointless update that changes nothing but costs several
microseconds (about a 50% increase in time taken). The update is
fast, but there are comparisons and some useless programming.
Leave TODOs indicating dissatisfaction.
Signed-off-by: David Francis <David.Francis@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
amdgpu_dm_commit_planes was performing multi-plane
flips incorrectly:
It waited for vblank once per flipped plane
It prepared flip ISR and acquired the corresponding vblank ref
once per plane, although it closed ISR and put the ref once
per crtc
It called into dc once per flipped plane, duplicating some work
[How]
Wait for vblank, get vblank ref, prepare flip ISR, and call into
DC only once, and only if there is a pageflip
Make freesync continue to update planes even if vrr information
has already been changed
Signed-off-by: David Francis <David.Francis@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Underscan and ABM are connector properties but require updates
to DC stream state. Previously, on updates to these properties
the affected stream and all its planes were committed.
This is unnecessary; only a few fields on the stream need
to be changed.
[How]
If scaling or ABM have changed, change the stream and
create a stream update with those changes. Call
DC with only those fields.
Signed-off-by: David Francis <David.Francis@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Replace kzalloc() function with its 2-factor argument form, kcalloc().
This patch replaces cases of:
kzalloc(a * b, gfp)
with:
kcalloc(a, b, gfp)
Also, improve the coding style and the use of sizeof during
allocation by changing sizeof(struct dc_surface_update) and
sizeof(struct dc_plane_state) to sizeof(*updates) and
sizeof(*surfaces), correspondingly.
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Need to check if crtc state is changed so that mode set is
required before trying to create new stream.
It deals with the MST hotplug use case when plug back to the
same connector where the failure to create new stream for the
inactive crtc on the old connector.
Signed-off-by: Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Backlight is conceptually a property of links, not streams.
All backlight programming is done on links, but there is a
stream property bl_pwm_level that is used to restore backlight
on dpms on and s3 resume. This is unnecessary, as backlight
is already restored by hardware with no driver intervention.
[How]
Remove bl_pwm_level, and the stream argument to set_backlight
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=109375
Signed-off-by: David Francis <David.Francis@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Acked-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 923fe49512)
[Why]
This fixes a stuttering issue that occurs when moving a hardware cursor
when VRR is enabled.
Previously when VRR is enabled atomic check will grab the connector
state for every atomic update. This has to lock the connector in order
to do so. The locking is bad enough by itself for performance, but
it gets worse with what we do just below that - add all the planes
for the CRTC to the commit.
This prevents the cursor fast path from working - there's more than one
plane now. With state->allow_modeset = true on top of this, it also
adds and removes all the planes from the DC context triggering a full
(very slow) update in DC.
[How]
We need the connector state to get the VRR min/max capbilities, but we
only need them when there's a CRTC mode change or when VRR is toggled.
The condition has been updated accordingly.
Fixes: 3cc22f281318 ("drm/amdgpu: Set FreeSync state using drm VRR properties")
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This reverts commit 717276b925.
The reverted patch was a workaround that addressed an issue fixed by:
4364bcb2cd ("drm: Get ref on CRTC commit object when waiting for
flip_done")
Signed-off-by: Leo Li <sunpeng.li@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
This fixes a stuttering issue that occurs when moving a hardware cursor
when VRR is enabled.
Previously when VRR is enabled atomic check will grab the connector
state for every atomic update. This has to lock the connector in order
to do so. The locking is bad enough by itself for performance, but
it gets worse with what we do just below that - add all the planes
for the CRTC to the commit.
This prevents the cursor fast path from working - there's more than one
plane now. With state->allow_modeset = true on top of this, it also
adds and removes all the planes from the DC context triggering a full
(very slow) update in DC.
[How]
We need the connector state to get the VRR min/max capbilities, but we
only need them when there's a CRTC mode change or when VRR is toggled.
The condition has been updated accordingly.
Fixes: 3cc22f281318 ("drm/amdgpu: Set FreeSync state using drm VRR properties")
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
To reduce indent in dm_update_crtcs, and to make it operate on single
instances.
[How]
Move iteration of plane states into atomic_check.
No functional change is intended.
Signed-off-by: Leo Li <sunpeng.li@amd.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
To reduce indentation of dm_update_planes, and to make it operate on
single plane instances.
[How]
Move iteration of plane states into atomic_check.
No functional change is intended.
Signed-off-by: Leo Li <sunpeng.li@amd.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Hardware support for Delta Color Compression (DCC) decompression is
available in DC for GFX9 but there's no way for userspace to enable
the feature.
Enabling the feature can provide improved GFX performance and
power savings in many situations.
[How]
The GFX9 DCC parameters are passed to amdgpu_dm from AMDGPU via the
amdgpu_bo tiling_flags. The plane capability is queried and the
parameters are set accordingly.
The DCC address is given via a 256 byte aligned offset on the
framebuffer address. The DCC address is updated whenever the buffer
address changes.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
The function dc_commit_updates_for_stream had a parameter called
plane_states. It was never used. It was getting in the way
of some cleanup work
[How]
Remove it
Signed-off-by: David Francis <David.Francis@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
This fixes an regression introduced by:
drm/amd/display: add stream ID and otg instance in dc_stream_state
During driver initialization, a null pointer deref is raised. This is
caused by searching for a stream status in the dc->current_state before
the dc_state swap happens at the end of dc_commit_state_no_check().
Since the swap has not happened, the dc_state to be swapped in should
be searched, and not dc->current_state.
[How]
Add a function that searches for the stream status within the given
dc_state, instead of dc->current_state. Use that before the state swap
happens in dc_commit_state_no_check().
Also remove duplicate occurrences of this function in amdgpu_dm.c.
Signed-off-by: Leo Li <sunpeng.li@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Acked-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Users would like more accurate pixel clocks, especially for fractional
"TV" frame rates like 59.94 Hz.
[How]
Store and communicate pixel clocks with 100 Hz accuracy from
dc_crtc_timing through to BIOS command table setpixelclock call.
Signed-off-by: Ken Chalmers <ken.chalmers@amd.com>
Reviewed-by: Charlene Liu <Charlene.Liu@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Backlight is conceptually a property of links, not streams.
All backlight programming is done on links, but there is a
stream property bl_pwm_level that is used to restore backlight
on dpms on and s3 resume. This is unnecessary, as backlight
is already restored by hardware with no driver intervention.
[How]
Remove bl_pwm_level, and the stream argument to set_backlight
Signed-off-by: David Francis <David.Francis@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Acked-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
dc_stream_state containing a pointer to sink is poor design.
Sink describes the display, and the specifications or capabilities
it has. That information is irrelevant for dc_stream_state, which describes
hardware state, and is generally used for hardware programming. It
could further be argued that dc_sink itself is just a convenience dc
provides, and DC should be perfectly capable of programming hardware
without any dc_sinks (for example, emulated sinks).
[how]
Phase 1:
Deprecate use of dc_sink pointer in dc_stream. Most references are trivial
to remove, but some call sites are risky (such as is_timing_changed) with
no obvious logical replacement. These will be removed in follow up change.
Add dc_link pointer to dc_stream. This is the typical reason DC really needed
sink pointer, and most call sites are replaced with this.
DMs also need minor updates, as all 3 DMs leverage stream->sink for
some functionality. this is replaced instead by a pointer to private data
inside dc_stream_state, which is used by DMs as a quality of life improvment
for some key functionality. it allows DMs to set pointers have to their own objects
which associate OS objects to dc_stream_states (such as DisplayTarget
and amdgpu_dm_connector). Without the private pointer, DMs would be
forced to perform a lookup for callbacks.
Signed-off-by: Jun Lei <Jun.Lei@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: David Francis <David.Francis@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
UAPI Changes:
Cross-subsystem Changes:
- Turn dma-buf fence sequence numbers into 64 bit numbers
Core Changes:
- Move to a common helper for the DP MST hotplug for radeon, i915 and
amdgpu
- i2c improvements for drm_dp_mst
- Removal of drm_syncobj_cb
- Introduction of an helper to create and attach the TV margin properties
Driver Changes:
- Improve cache flushes for v3d
- Reflection support for vc4
- HDMI overscan support for vc4
- Add implicit fencing support for rockchip and sun4i
- Switch to generic fbdev emulation for virtio
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXDOTqAAKCRDj7w1vZxhR
xZ8QAQD4j8m9Ea3bzY5Rr8BYUx1k+Cjj6Y6abZmot2rSvdyOHwD+JzJFIFAPZjdd
uOKhLnDlubaaoa6OGPDQShjl9p3gyQE=
=WQGO
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-next-2019-01-07-1' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for 5.1:
UAPI Changes:
Cross-subsystem Changes:
- Turn dma-buf fence sequence numbers into 64 bit numbers
Core Changes:
- Move to a common helper for the DP MST hotplug for radeon, i915 and
amdgpu
- i2c improvements for drm_dp_mst
- Removal of drm_syncobj_cb
- Introduction of an helper to create and attach the TV margin properties
Driver Changes:
- Improve cache flushes for v3d
- Reflection support for vc4
- HDMI overscan support for vc4
- Add implicit fencing support for rockchip and sun4i
- Switch to generic fbdev emulation for virtio
Signed-off-by: Dave Airlie <airlied@redhat.com>
[airlied: applied amdgpu merge fixup]
From: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190107180333.amklwycudbsub3s5@flea
This is an ugly one unfortunately. Currently, all DRM drivers supporting
atomic modesetting will save the state that userspace had set before
suspending, then attempt to restore that state on resume. This probably
worked very well at one point, like many other things, until DP MST came
into the picture. While it's easy to restore state on normal display
connectors that were disconnected during suspend regardless of their
state post-resume, this can't really be done with MST because of the
fact that setting up a downstream sink requires performing sideband
transactions between the source and the MST hub, sending out the ACT
packets, etc.
Because of this, there isn't really a guarantee that we can restore the
atomic state we had before suspend once we've resumed. This sucks pretty
bad, but so far I haven't run into any compositors that this actually
causes serious issues with. Most compositors will notice the hotplug we
send afterwards, and then reprobe state.
Since nouveau and i915 also don't fail the suspend/resume process due to
failing to restore the atomic state, let's make amdgpu match this
behavior. Better to resume the GPU properly, then to stop the process
half way because of a potentially unavoidable atomic commit failure.
Eventually, we'll have a real fix for this problem on the DRM level. But
we've got some more important low-hanging fruit to deal with first.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Cc: Jerry Zuo <Jerry.Zuo@amd.com>
Cc: <stable@vger.kernel.org> # v4.15+
Link: https://patchwork.freedesktop.org/patch/msgid/20190108211133.32564-3-lyude@redhat.com
drm_dp_mst_topology_mgr_resume() returns whether or not it managed to
find the topology in question after a suspend resume cycle, and the
driver is supposed to check this value and disable MST accordingly if
it's gone-in addition to sending a hotplug in order to notify userspace
that something changed during suspend.
Currently, amdgpu just makes the mistake of ignoring the return code
from drm_dp_mst_topology_mgr_resume() which means that if a topology was
removed in suspend, amdgpu never notices and assumes it's still
connected which leads to all sorts of problems.
So, fix this by actually checking the rc from
drm_dp_mst_topology_mgr_resume(). Also, reformat the rest of the
function while we're at it to fix the over-indenting.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Cc: Jerry Zuo <Jerry.Zuo@amd.com>
Cc: <stable@vger.kernel.org> # v4.15+
Link: https://patchwork.freedesktop.org/patch/msgid/20190108211133.32564-2-lyude@redhat.com
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJcL65eAAoJEAx081l5xIa+y7EP+wQnTk3GV7rKiIi5LEtux5xW
X2tTaPKHnwrMYjRaP2VNUntJPH6Wxcby3OHGNvGMe1IqNGL/5qRLQ/g1rSSPuM4z
rYwWR/ooDU/KwYvsT/o+DSO62AoVzIqx8gn8+ShirRN3MdobCcwDebd5oqKjduOn
hRy9WQwgPOnDG1D3fRWOGSzOE1K9yDFCUaR0AmhUehn9NvsztQGamMBBwMNg+y52
a5vu+nSLxQrv3ZyZ5TQUgAzi2pWFtC6QxIVuLpl5TqFA3vdRVyN1T78klDnQ7WU7
6GY1yq9D923c1Tfa0RZoXnE++bX91KKJ5y9YFuNFv8X/th6UoEzRrOPDINfLoZv3
JsPPSPAiZTgoXc/RGfoMbnidajNB7Gx+No+Pd8P6MeY5H1E+ivMXt5MrOgcMXUqk
FajthiuSlaB+u5OjNjuS6gBbAMIKw7Idg4hEFSabj91qhJIet/fPhzNmp0HPJ1wF
XlNnxI7XOytCAORrjLy2q4/lkaoG2AlVpZzeMLgXSxGGlSCtIpDUIqgQbtV1ppCi
RboQ8yMflRejeK6oXoC92mI8yDB6rwoQy2tK0Hvnag5/q1r7AVYJq+3890NFEU4X
F5TuCgvhswdkTEJUED1G6pnX7aQzW0dh6KrCltF34sFzD1etYb150En7laa+2kmX
G5HfZbkLwscPt91moA6B
=hFld
-----END PGP SIGNATURE-----
Merge tag 'drm-next-2019-01-05' of git://anongit.freedesktop.org/drm/drm
Pull drm fixes from Dave Airlie:
"Happy New Year, just decloaking from leave to get some stuff from the
last week in before rc1:
core:
- two regression fixes for damage blob and atomic
i915 gvt:
- Some missed GVT fixes from the original pull
amdgpu:
- new PCI IDs
- SR-IOV fixes
- DC fixes
- Vega20 fixes"
* tag 'drm-next-2019-01-05' of git://anongit.freedesktop.org/drm/drm: (53 commits)
drm: Put damage blob when destroy plane state
drm: fix null pointer dereference on null state pointer
drm/amdgpu: Add new VegaM pci id
drm/ttm: Use drm_debug_printer for all ttm_bo_mem_space_debug output
drm/amdgpu: add Vega20 PSP ASD firmware loading
drm/amd/display: Fix MST dp_blank REG_WAIT timeout
drm/amd/display: validate extended dongle caps
drm/amd/display: Use div_u64 for flip timestamp ns to ms
drm/amdgpu/uvd:Change uvd ring name convention
drm/amd/powerplay: add Vega20 LCLK DPM level setting support
drm/amdgpu: print process info when job timeout
drm/amdgpu/nbio7.4: add hw bug workaround for vega20
drm/amdgpu/nbio6.1: add hw bug workaround for vega10/12
drm/amd/display: Optimize passive update planes.
drm/amd/display: verify lane status before exiting verify link cap
drm/amd/display: Fix bug with not updating VSP infoframe
drm/amd/display: Add retry to read ddc_clock pin
drm/amd/display: Don't skip link training for empty dongle
drm/amd/display: Wait edp HPD to high in detect_sink
drm/amd/display: fix surface update sequence
...
Resolves __udivdi3 missing errors when building for i386.
Fixes: 6378ef012ddc ("drm/amd/display: Add below the range support for FreeSync")
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
When the flip-rate is below the minimum supported variable refresh rate
range for the monitor the front porch wait will timeout and be
frequently misaligned resulting in stuttering and/or flickering.
The FreeSync module can still maintain a smooth and flicker free
image when the monitor has a refresh rate range such that the maximum
refresh > 2 * minimum refresh by utilizing low framerate compensation,
"below the range".
[How]
Hook up the pre-flip and post-flip handlers from the FreeSync module.
These adjust the minimum/maximum vrr range to duplicate frames
when appropriate by tracking flip timestamps.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
