[Why]
In some usecases, like tiled display, the stream and plane configuration
can be setup in a way where the caller expects DAL to perform the
clipping, eg:
P0:
src_rect(0, 0, w, h)
dst_rect(0, 0, w, h)
P1:
src_rect(w, 0, w, h)
dst_rect(0, 0, w, h)
Cursor is enabled on both streams with the same position.
This can result in double cursor on tiled display, even though this
behavior is technically correct from the DC interface point of view.
We need a mechanism to control this dynamically.
[How]
This is something that should live in the DM layer based on detection
of the specified configuration but it's not something that we really
have enough information to deal with today.
Add a flag to the cursor position state that specifies whether we
want DC to do the translation or not and make it opt-in and let
the DM decide when to do it.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
If a plane isn't being actively enabled or disabled then DC won't
always recalculate scaling rects and ratios for the primary plane.
This results in only a partial or corrupted rect being displayed on
the screen instead of scaling to fit the screen.
[How]
Add back the logic to recalculate the scaling rects into
dc_commit_updates_for_stream since this is the expected place to
do it in DC.
This was previously removed a few years ago to fix an underscan issue
but underscan is still functional now with this change - and it should
be, since this is only updating to the latest plane state getting passed
in.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
For medium updates that change nothing but the source rect position
the viewport doesn't change on DCN20.
We're missing the check for the position update bit that was there in
the DCN10 hardware sequencer.
[How]
Check the position bit along with the scaling bit like we were doing
with DCN20.
We shouldn't actually hit a case where context != current_state in
our programming/commit model but guard against it anyway since it was
guarded for the other bits.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Zhan Liu <Zhan.Liu@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Cursor pos is correctly adjusted from DC side for source rect offset
on DCN ASIC, but only on the overlay.
This is because DM places offsets the cursor for primary planes only
to workaround missing code in DCE for the adjustment we're now correctly
doing in DC for DCN ASIC.
[How]
Drop the adjustment for source rect from the DM side of things and put
the code where it actually belongs - in DC on the pipe level.
This matches what we do for DCN now.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Zhan Liu <Zhan.Liu@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Cursor is drawn as part of the framebuffer for a plane on AMD hardware.
The cursor position on the framebuffer does not change even if the
source rect viewport for the cursor does. This causes the cursor to be
clipped.
The following IGT tests fail as a result of this issue:
- kms_plane_cursor@pipe-*-viewport-size-*
[How]
Offset cursor position by plane source rect viewport. If the viewport
is unscaled then the cursor is now correctly positioned on any
plane - primary or overlay.
There is still a hardware limitation for dealing with the cursor size
being incorrectly scaled but that's not something we can address.
Add some documentation explaining some of this in the code while we're
at it.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Zhan Liu <Zhan.Liu@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
After v_total_min and max are updated in vrr structure, the changes are
not reflected in stream adjust. When these values are read from stream
adjust it does not reflect the actual state of the system.
[How]
Set stream adjust values equal to vrr adjust values after vrr adjust
values are updated.
Signed-off-by: Isabel Zhang <isabel.zhang@amd.com>
Reviewed-by: Alvin Lee <Alvin.Lee2@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
DRM already supports tracing DPCD transactions, there's no reason for
the existence of this function. Also, it prints one byte per-line which
is way too loud. So, just remove it.
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Removes codestyle issues in dc_link file, on dc_link_construct and
translate_encoder_to_transmitter as suggested by checkpatch.pl.
Types covered:
CHECK: Lines should not end with a '('
WARNING: Missing a blank line after declarations
CHECK: Alignment should match open parenthesis
CHECK: Comparison to NULL could be written
CHECK: Logical continuations should be on the previous line
CHECK: Blank lines aren't necessary after an open brace '{'
Signed-off-by: Melissa Wen <melissa.srw@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Removes codestyle issues on the file dc_link between is_same_edid and
get_ddc_line as suggested by checkpatch.pl.
Types covered:
CHECK: Blank lines aren't necessary after an open brace '{'
CHECK: Blank lines aren't necessary before a close brace '}'
WARNING: braces {} are not necessary for single statement blocks
CHECK: Comparison to NULL could be written
CHECK: Lines should not end with a '('
CHECK: Alignment should match open parenthesis
CHECK: Using comparison to false is error prone
CHECK: Using comparison to true is error prone
WARNING: Avoid multiple line dereference - prefer 'link->dpcd_caps.sink_count.bits.SINK_COUNT'
CHECK: Unnecessary parentheses around
WARNING: Missing a blank line after declarations
Signed-off-by: Melissa Wen <melissa.srw@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Removes codestyle issues on the file dc_link until detect_dp func as
suggested by checkpatch.pl.
Types covered:
CHECK: Please don't use multiple blank lines
CHECK: Comparison to NULL could be written
ERROR: space required before the open parenthesis '('
CHECK: Alignment should match open parenthesis
CHECK: Lines should not end with a '('
WARNING: please, no space before tabs
WARNING: Comparisons should place the constant on the right side of the test
WARNING: braces {} are not necessary for single statement blocks
CHECK: Please don't use multiple blank lines
Signed-off-by: Melissa Wen <melissa.srw@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Can't call dmub_abm_enable_fractional_pwm from dmub_abm_create as
dmub_srv is still null at this init stage, and therefore can't call to
fw.
[How]
Move call to dmub_abm_init_backlight. This should be the first call from
the driver for ABM.
Signed-off-by: Wyatt Wood <wyatt.wood@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
CTM was only supported at CRTC level and we need color space conversion
in linear space at plane level.
[How]
- Add plane-level CTM to dc interface
- Program plane-level CTM in DCN
Signed-off-by: Stylon Wang <stylon.wang@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
In some scenario like 1366x768 VSR enabled connected with a 4K monitor
and playing 4K video in clone mode, underflow will be observed due to
decrease dppclk when previouse surface scan isn't finished
[How]
In this use case, surface flip is switching between 4K and 1366x768,
1366x768 needs smaller dppclk, and when decrease the clk and previous
surface scan is for 4K and scan isn't done, underflow will happen. Not
doing optimize bandwidth in case of flip pending.
Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
For some monitors extreme flickering can occur while using LFC for if
we're not doing the DRR timing update for V_TOTAL_MIN / V_TOTAL_MAX at
the DP start of frame.
Hardware can default to any time in the frame which isn't the behavior
we want.
[How]
Add a new function for setting the double buffering mode for DRR timing.
Default to DP start of frame double buffering on timing generator init.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Diagnostics scaling test failing to set required number of vertical taps
in 4:2:0 surface case
[How]
In dpp3_get_optimal_number_of_taps() need to use LB_MEMORY_CONFIG_3 for
4:2:0 surface case. In resource_build_scaling_params() make sure to also
set plane res alpha enable based on updated surface state
Signed-off-by: Eric Bernstein <eric.bernstein@amd.com>
Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
before update dpp DTO, we check dppclks in context to determine it is
changed or not, but dppclks in context will be updated anyways after
flip is done, so compare dppclks in context will always get an equal
result.
[How]
Add pipe dpp clks in dccg and compare values between dccg and context.
Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com>
Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
underflow happened when playing video on 1366x768 + 4K clone mode due to
incorrect handle watermark change flag and lower down clocks to early.
[How]
Check watermark change flag when decide doing optimized, and check
optimized required flag to do clock update.
Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com>
Reviewed-by: Eric Yang <eric.yang2@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
We should check MST BU support capability on output port before building
vsc info packet.
[How]
Add a new definition for port and sink capability check.
Signed-off-by: Martin Tsai <martin.tsai@amd.com>
Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[WHY]
In headless boot cases, self refresh control registers are not
programmed on boot. In certain hybrid graphics cases this may cause
cstate entering to get blocked causing a hang.
[HOW]
Program self refresh control register on boot.
Signed-off-by: Sung Lee <sung.lee@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
A "dcn20_program_front_end_for_ctx" warning is observed on Renoir.
Since the resource definition doesn't explicitly disable triplebuffer
flips like Navi10 DC actually attempts to go and setup triplebuffering
even when we pass in false to the plane state.
If we hit a full update after triplebuffering has been setup we see the
assertion since we don't expect full updates while performing
triplebuffer flips.
Normally this would get reset back to false whne we pass in the new
plane state, but since we never actually copy the flag when doing
surface updates this doesn't happen.
[How]
Copy the flag onto the plane update based on the requested surface
update state.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Hersen Wu <hersenxs.wu@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
When hotplug a HDMI monitor during entering S0i3 or DPMSOFF state due to
entering infinite loop when calling vbios to program pixel clocks. In
this scenario, pll is enabled but phy is not, and there is not a
programing guide for this case.
[How]
Before we having the proper programing guide, before disable pll, doing
a phy enable and disable to avoid the issue.
Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
When reprogram MSA with updated color space, the test color space shows
inconsistency. Linux has separate routine to set up test pattern color
space, but it fails to configure RGB.
[How]
Add RGB to test pattern.
Fixes: 43563bc2e6 ("drm/amd/display: update MSA and VSC SDP on video test pattern request")
Signed-off-by: Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com>
Reviewed-by: Hersen Wu <hersenxs.wu@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This fixes a problem found on the MacBookPro 2017 Retina panel:
The panel reports 10 bpc color depth in its EDID, and the
firmware chooses link settings at boot which support enough
bandwidth for 10 bpc (324000 kbit/sec aka LINK_RATE_RBR2
aka 0xc), but the DP_MAX_LINK_RATE dpcd register only reports
2.7 Gbps (multiplier value 0xa) as possible, in direct
contradiction of what the firmware successfully set up.
This restricts the panel to 8 bpc, not providing the full
color depth of the panel on Linux <= 5.5. Additionally, commit
'4a8ca46bae8a ("drm/amd/display: Default max bpc to 16 for eDP")'
introduced into Linux 5.6-rc1 will unclamp panel depth to
its full 10 bpc, thereby requiring a eDP bandwidth for all
modes that exceeds the bandwidth available and causes all modes
to fail validation -> No modes for the laptop panel -> failure
to set any mode -> Panel goes dark.
This patch adds a quirk specific to the MBP 2017 15" Retina
panel to override reported max link rate to the correct maximum
of 0xc = LINK_RATE_RBR2 to fix the darkness and reduced display
precision.
Please apply for Linux 5.6+ to avoid regressing Apple MBP panel
support.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
If "speed" is zero then we use it as a divisor to find "prescale". It's
better to move the check for zero to the very start of the function.
Fixes: 9eeec26a13 ("drm/amd/display: Refine i2c frequency calculating sequence")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We can remove the NULL check for "res_ctx" and
"res_ctx->pipe_ctx[i].stream->link". Also it's nicer to align the
conditions using spaces so I re-indented a bit.
Longer explanation: The "res_ctx" pointer points to an address in the
middle of a struct so it can't be NULL. For
"res_ctx->pipe_ctx[i].stream->link" we know that it is equal to "link"
and "link" is non-NULL.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
In dcn20_funcs and dcn21_funcs struct, the member ".dsc_pg_control = NULL"
should be removed due to .dsc_pg_control be assigned to dcn20_dsc_pg_control.
Signed-off-by: Stanley.Yang <Stanley.Yang@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Problem Description:
Currently we are checking internal fused rev id with pci rev id. However, fused
internal rev id is the same on all raven2 parts (in which Dali and Pollock were
based on too), thus Pollock detection fails
Fix:
use the pci rev to preform the detection for bandwidth calculations.
Reviewed-by: Feifei Xu <Feifei.Xu@amd.com>
Signed-off-by: Aly-Tawfik <altawfik@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
FEC capability query should not be affected by debugging decision on
whether to disable FEC. We should not determine if display supports FEC
by checking debug option.
Signed-off-by: Wenjing Liu <Wenjing.Liu@amd.com>
Reviewed-by: Ashley Thomas <Ashley.Thomas2@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
on some displays that prefer swapped polarity we were seeing L/R images
swapped because OTG_STEREO_SYNC_OUTPUT_POLARITY would always be mapped
to 0
[how]
fix initial dal3 implementation to properly update the polarity field
according to the crtc_stereo_flags (same as
OTG_STEREO_EYE_FLAG_POLARITY)
Signed-off-by: Martin Leung <martin.leung@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
Link or DIG BE can't be exposed to a higher stream bandwidth than they
can handle. When DSC is required to fit the stream into the link
bandwidth, DSC has to be programmed during timing programming to ensure
this. Without it, intermittent issues such as black screen after S3 or a
hot-plug can be seen.
[how]
Move DSC programming from enabling stream on link to timing setup.
Signed-off-by: Nikola Cornij <nikola.cornij@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
System isn't able to enter S0i3 due to not send display count 0 to smu.
When dpms off, clk changed flag is cleared alreay, and it is checked
when doing optimized bandwidth, and update clocks is bypassed due to the
flag is unset.
[How]
Remove check flag incide the function since watermark values and clocks
values are checked during update to determine whether to perform it, no
need to check it again outside the function.
Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
