[Why]
New seamless boot sequence introduced a bug where front end is disabled
without blanking otg.
[How]
Adjust the condition of blanking otg to match seamless boot.
Signed-off-by: Eric Yang <Eric.Yang2@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Acked-by: Tony Cheng <Tony.Cheng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Before it was returning false in the case of failure even though return type should be enum dc_status
[How]
Return DC_FAIL_UNSUPPORTED_1 instead
Signed-off-by: Su Sung Chung <Su.Chung@amd.com>
Reviewed-by: Eric Yang <eric.yang2@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
The input color space for the plane was previously ignored even if it
was set.
If a limited range YUV format was given to DC then the
wrong color transformation matrix was being used since DC assumed that
it was full range instead.
[How]
Respect the given color_space format for the plane if it isn't
COLOR_SPACE_UNKNOWN. Otherwise, use the implicit default since DM
didn't specify.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com>
Acked-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
If the cursor pos passed from DM is less than the plane_state->dst_rect
top left corner then the unsigned cursor pos wraps around to a large
positive number since cursor pos is a u32.
There was an attempt to guard against this in hubp1_cursor_set_position
by checking the src_x_offset and src_y_offset and offseting the
cursor hotspot within hubp1_cursor_set_position.
However, the cursor position itself is still being programmed
incorrectly as a large value.
This manifests itself visually as the cursor disappearing or containing
strange artifacts near the middle of the screen on raven.
[How]
Don't subtract the destination rect top left corner from the pos but
add it to the hotspot instead. This happens before the pos gets
passed into hubp1_cursor_set_position.
This achieves the same result but avoids the subtraction wrap around.
With this fix the original cursor programming logic can be used again.
v2: add hunk that got dropped accidently when this patch was originally
committed. (Alex)
Fixes: 0921c41e19 ("drm/amd/display: Fix negative cursor pos programming")
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Charlene Liu <Charlene.Liu@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Acked-by: Murton Liu <Murton.Liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
The actual position for the cursor on the screen is essentially:
x_out = x - x_plane - x_hotspot
y_out = y - y_plane - y_hotspot
The register values for cursor position and cursor hotspot need to be
greater than zero when programmed, but we also need to subtract off
the plane position to display the cursor at the correct position.
Since we don't want x or y to be less than zero, we add the plane
position as a positive value to x_hotspot or y_hotspot. However, what
this doesn't take into account is that the hotspot registers are limited
by the maximum cursor size.
On DCN10 the cursor hotspot regitsers are masked to 0xFF, so they have
a maximum value of 0-255. Values greater this will wrap, causing the
cursor to display in the wrong position.
In practice this means that for sufficiently large plane positions, the
cursor will be drawn twice on the screen, and can cause screen flashes
or p-state WARNS depending on what the wrapped value is.
So we need a way to remove the value from x_plane and y_plane without
exceeding the maximum cursor size.
[How]
Subtract as much as x_plane/y_plane as possible from x and y and place
the remainder in the cursor hotspot register.
The value for x_hotspot and y_hotspot can still wrap around but it
won't happen in a case where the cursor is actually enabled.
The cursor plane needs to intersect at least one pixel of the plane's
rectangle to be enabled, so the cursor position + hotspot provided by
userspace must always be strictly less than the maximum cursor size for
the cursor to actually be enabled.
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]
Multiple threads were writing back to one global VBA in DC resulting
in multiple threads overwriting eachother's data
[How]
Add an instance of DML (which contains VBA) to each context and
change all calls that used dc->dml to use context->dml. Created a
seperate copy constructor for linux in a case where there is no
access to DC.
Signed-off-by: Aidan Wood <Aidan.Wood@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
amdgpu:
- Switch to HMM for userptr (reverted until HMM fixes land)
- New experimental SMU 11 replacement for powerplay for vega20 (not enabled by default)
- Initial RAS support for vega20
- BACO support for vega12
- BACO fixes for vega20
- Rework IH handling for page fault and retry interrupts
- Cleanly split CPU and GPU paths for GPUVM updates
- Powerplay fixes
- XGMI fixes
- Rework how DC interacts with atomic for planes
- Clean up and simplify DC/Powerplay interfaces
- Misc cleanups and bug fixes
amdkfd:
- Switch to HMM for userptr (reverted until HMM fixes land)
- Add initial RAS support
- MQD fixes
ttm:
- Unify DRM_FILE_PAGE_OFFSET handling
- Account for kernel allocations in kernel zone only
- Misc cleanups
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190402170820.22197-1-alexander.deucher@amd.com
[why]
existing logic finds "first free pipe from 5 -> 0" to split
this will cause certain sequences to require DC to move
an MPCC from one tree to another, which is unsupported
this leads to blackscreen
to mitigate this problem, we will always try to acquire the
"preferred" pipe, and each pipe has a unique preferred pipe
this means we avoid most of the scenarios where
pipe splitting leads to moving MPCC from one tree
to another
Signed-off-by: Jun Lei <Jun.Lei@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Description]
when programming VID_TIMING, we were using the original VESA timing for DP_VIDM/N.
for YCbCr420 or compressed YCbCr422, using half rate as YCbCr444.
Signed-off-by: Charlene Liu <charlene.liu@amd.com>
Reviewed-by: Nikola Cornij <Nikola.Cornij@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Need to set VID_N_MUL for 4:2:0 cases
[How]
Move setting to enc1_stream_encoder_dp_unblank and
ensure it is also set for non-4:2:0 cases.
Signed-off-by: Eric Bernstein <eric.bernstein@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
"reference clock" is a very overloaded variable in DC and causes confusion
as there are multiple sources of reference clock, which may be different values
incorrect input values to DML will cause DCHUB to be programmed improperly
and lead to hard to debug underflow issues
[how]
instead of using ref clock everywhere, specify WHICH ref clock:
- xtalin
- dccg refclk
- dchub refclk
these are all distinct values which may not be equal
Signed-off-by: Jun Lei <Jun.Lei@amd.com>
Reviewed-by: Yongqiang Sun <yongqiang.sun@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>
[Why]
field toggle write is actual field sequence write with the same
field name.
[How]
Use REG_UPDATE_SEQ_2 for both sequence write and toggle.
Rename REG_UPDATE_1by1_3 to REG_UPDATE_SEQ_3.
Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Current reg update and reg set use same functions and
only delta is update reads reg value and call update function.
[How]
Refactor reg update and reg set functions.
1.Implement different functions for reg update and reg set.
2.Wrap same process to a help function, both reg update and
reg set will call it.
Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
UEFI boot usually uses a boot profile that uses higher clocks
and watermark settings.
UEFI boot surface is less optimal, for example it uses linear surface
[How]
Before we finish our seamless boot sequence, keep the clock and
watermark settings from boot.
Update to optimal settings only after first flip away from UEFI
frame buffer.
Signed-off-by: Anthony Koo <Anthony.Koo@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
The current dc_caps doesn't provide the information needed to
determine the count and type of each plane to be exposed to userspace.
There are three types of DRM planes that are exposed to userspace:
1. Primary planes (can be used for modesetting)
2. Overlay planes (can be blended below or above a primary plane)
3. Cursor planes (blended topmost)
We need to know the number and type of each in amdgpu_dm to expose
to userspace.
Hardware supports blending planes below, above or both ways depending
on the ASIC. Alpha support is also ASIC dependent. Some hardware has
dedicated pipes for overlays and other hardware combines the pipes.
All of this should be exposed in a way that DM can query and use.
[How]
Introduce the dc_plane_cap structure that describes the capabilities
for the hw planes.
It describes:
- the type of the plane
- whether the plane can blend with planes below it
- whether the plane can blend with planes above it
- whether the plane supports per pixel alpha blending
- supported formats on the plane (partial list for now)
Pre DCN ASICs don't have their full capabilities described for now.
They can be updated as needed in the future.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[WHY]
When doing split pipe, if one pipe is pending on flip, the entire
plane's status should be flip pending, otherwise corruption can occur
when OS writes to a surface prematurely.
[HOW]
Clear the flip pending bit before checking pipes, then OR the flip
pending bits from all pipes together to create the flip pending status
of the entire plane.
Signed-off-by: Wesley Chalmers <Wesley.Chalmers@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Eryk Brol <Eryk.Brol@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Seamless boot tries to reuse planes that were enabled for the first
commit applied.
In the case where Raven is booting with two monitors connected and the
first commit contains two streams the screen corruption would occur
because the second stream was trying to re-use a tg and plane that
weren't previously enabled.
The state on the first commit looks something like the following:
TG0: enabled=1
TG1: enabled=0
TG2: enabled=0
TG3: enabled=0
New state: pipe=0, stream=0, plane=0, new_tg=0
New state: pipe=1, stream=1, plane=1, new_tg=1
New state: pipe=2, stream=NULL, plane=NULL, new_tg=NULL
New state: pipe=3, stream=NULL, plane=NULL, new_tg=NULL
Only one plane/tg is setup before we enter accelerated mode so
we really want to disabling everything but that first plane.
[How]
Check if the stream is not NULL and if the tg is enabled before
deciding whether to skip the plane disable.
Also ensure we're also disabling on the current state's pipe_ctx so
we don't overwrite the fields in the new pending state.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Harry Wentland <Harry.Wentland@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This change changes dc add plane logic to allow plane-less resource
reservation (pipe split).
If a free pipe_ctx (no plane_state attached) is the head pipe, and is
found with a bottom pipe attached, assign the plane to add on the bottom
pipe.
In addition, prepend dcn10 to dcn10-specific reset_back_end_for_pipe
and reset_hw_ctx_wrap
Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@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>
Driver need to poll the SURFACE_INUSE register to determine when to
start the new task and write data to the checked surface.
Implement the wait functions, and add the necessary hubbub registers.
Signed-off-by: Charlene Liu <charlene.liu@amd.com>
Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Seamless boot code not working on all ASICs because of
some underflow issues caused by some uninitialized HW
state.
[How]
Keep some logical and power gating init code in hw_init.
Move some per pipe init code to enable accelerated mode
Signed-off-by: Anthony Koo <Anthony.Koo@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Make dml and integration with pplib clearer.
[How]
Change the way the dml formula is initialized to make its values more
clear. Restructure DC interface with pplib into rv_funcs.
Cap clocks received from pplib.
Signed-off-by: Jun Lei <Jun.Lei@amd.com>
Signed-off-by: Eryk Brol <eryk.brol@amd.com>
Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
There is a really hairy resolution involving amdgpu fixes, that I'd rather confirm here.
Also some misc fixes are landed by me, but the pr has them as well.
Signed-off-by: Dave Airlie <airlied@redhat.com>
[Why]
If the cursor pos passed from DM is less than the plane_state->dst_rect
top left corner then the unsigned cursor pos wraps around to a large
positive number since cursor pos is a u32.
There was an attempt to guard against this in hubp1_cursor_set_position
by checking the src_x_offset and src_y_offset and offseting the
cursor hotspot within hubp1_cursor_set_position.
However, the cursor position itself is still being programmed
incorrectly as a large value.
This manifests itself visually as the cursor disappearing or containing
strange artifacts near the middle of the screen on raven.
[How]
Don't subtract the destination rect top left corner from the pos but
add it to the hotspot instead. This happens before the pos gets
passed into hubp1_cursor_set_position.
This achieves the same result but avoids the subtraction wrap around.
With this fix the original cursor programming logic can be used again.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Charlene Liu <Charlene.Liu@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Acked-by: Murton Liu <Murton.Liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Current periodic interrupt start point calc in optc
is not clear.
[How]
1. DM convert delta time to lines number and dc will calculate the
start position as per lines number and interrupt type.
2. hwss calculates the start point as per line offset.
3. optc programs vertical interrupts register as per start point
and interrupt source.
Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Certain tests fail after a fresh reboot. This is caused by writing to
registers prior to ungating the stream we're trying to program.
[How]
Make sure the stream is ungated before writing to its registers.
This also enables power-gating plane resources before init_hw
initializes them.
Additionally, this does some refactoring to move gating/ungating
from enable/disable_plane functions to where stream resources are
enabled/disabled.
Signed-off-by: Gary Kattan <gary.kattan@amd.com>
Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
We want boot to desktop to be seamless
[How]
During init pipes, avoid touching the pipes where GOP has already
enabled the HW to the state we want.
Signed-off-by: Anthony Koo <Anthony.Koo@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
When stream is blanked, pipe set command is sent to dmcu to notify it
that the abm pipe is disabled. When stream is unblanked, no notification is
made to dmcu that the abm pipe has been enabled, resulting in abm not
being enabled in the firmware.
[How]
When stream is unblanked, send a pipe set command to dmcu.
Signed-off-by: Josip Pavic <Josip.Pavic@amd.com>
Reviewed-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]
Pipe related init is possible to optimized if we know what we
intend to program, and if we can determine it matches what is
already programmed for the pipe.
[How]
First step is to isolate the pipe related init code
Signed-off-by: Anthony Koo <Anthony.Koo@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Keep enable_stream_timing programming only
timing related stuff.
[How]
Move DRR and static screen mask programming from
enable_stream_timing to outside in
apply_single_controller_ctx_to_hw
Signed-off-by: Anthony Koo <Anthony.Koo@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Need to understand whether link is active aside from stream state.
This could be used to check what links are enabled by GOP.
[How]
Store link_active state in link status and initialize it by checking
if the DIG is enabled.
Keep it updated on every link enable and disable
Signed-off-by: Anthony Koo <Anthony.Koo@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
More clearly isolate the code that is involved in programming of
vupdate interrupt
[How]
Add function for programming of vupdate interrupt.
Call it after timing is programmed.
Signed-off-by: Anthony Koo <Anthony.Koo@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@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]
Need to figure out whether a timing we want to commit matches
something that GOP already programmed, in which case
we can decide to some optimizations
[How]
1. Add way to check for DIG FE
2. Add way to check for matching OTG timing
3. Add way to check for matching pixel clock (if possible)
- Currently only support DP for pixel clock, since it is easy to calc
Signed-off-by: Anthony Koo <Anthony.Koo@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
When moving mouse onto or off of pip plane,
screen would flash briefly due to garbage negative
pos values being programmed for cursor.
Also, text flashes due to PIP flips taking too long.
[How]
When negative pos value seen, default to 0 and adjust by modifying cursor hotspot.
For flip issue, only do post update when optimize required vs all the time.
Signed-off-by: Murton Liu <murton.liu@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Acked-by: Sivapiriyan Kumarasamy <Sivapiriyan.Kumarasamy@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[WHY]
Bandwidth calculation formulas currently do not take Stereo 3D + Stutter
properly into account. Disable stutter feature when we detect a Stereo
3D mode as a temporary workaround.
Signed-off-by: Wesley Chalmers <Wesley.Chalmers@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Acked-by: Martin Leung <Martin.Leung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
