A number of BIOS versions have a problem with the watermarks table not
being configured properly. This manifests as a very scary looking warning
during resume from s0i3. This should be harmless in most cases and is well
understood, so decrease the assertion to a clearer warning about the problem.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
configure_dp_hpo_throttled_vcp_size() was missing promotion before, but it was covered by
not calling the missing function hook in the old interface hpo_dp_link_encoder->funcs.
Recent refactor replaces with new caller link_hwss->set_throttled_vcp_size
which needs that hook, and that causes null ptr hang.
Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Unused. Convert the divisions into asserts on the divisor, to
debug why it is zero. The divide by zero is suspected of causing
kernel panics.
While I have no idea where the zero is coming from I think this
patch is a positive either way.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Change a static function's comment from "/**" (indicating kernel-doc
notation) to "/*" (indicating a regular C language comment).
This prevents multiple kernel-doc warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:4343: warning: Function parameter or member 'max_supported_frl_bw_in_kbps' not described in 'intersect_frl_link_bw_support'
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:4343: warning: Function parameter or member 'hdmi_encoded_link_bw' not described in 'intersect_frl_link_bw_support'
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:4343: warning: expecting prototype for Return PCON's post FRL link training supported BW if its non(). Prototype was for intersect_frl_link_bw_support() instead
Fixes: c022375ae0 ("drm/amd/display: Add DP-HDMI FRL PCON Support in DC")
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kernel test robot <lkp@intel.com>
Cc: Fangzhi Zuo <Jerry.Zuo@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Mirrors the logic for dcn30. Cue lots of WARNs and some
kernel panics without this fix.
Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
It calls populate_dml_pipes which uses doubles to initialize the
scale_ratio_depth params. Mirrors the dcn20 logic.
Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
In calculate_bandwidth(), the tag free_sclk and free_yclk are reversed,
which could lead to a memory leak of yclk.
Fix this bug by changing the location of free_sclk and free_yclk.
This bug was found by a static analyzer.
Builds with 'make allyesconfig' show no new warnings,
and our static analyzer no longer warns about this code.
Fixes: 2be8989d0f ("drm/amd/display/dc/calcs/dce_calcs: Move some large variables from the stack to the heap")
Signed-off-by: Zhou Qingyang <zhou1615@umn.edu>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
A porting error resulted in the stream assignment for the link
being retained without being released - a memory leak.
[How]
Fix the porting error by adding back the dc_stream_release() intended
as part of the original patch.
Fixes: 0bb2455585 ("drm/amd/display: retain/release at proper places in link_enc assignment")
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>
[Why]
To help triage issues and coordinate driver/bios release dependency
[How]
Only enable the new Z9 interface when debug option is set, otherwise
treat Z10 only support case as Zstate disallowed.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Eric Yang <Eric.Yang2@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
psr_feature_enabled flag is dynamically updated, and sometimes when
zstate allow status is determined the flag has not been set to true yet
even on PSR enabled config, lid off/on is such a case, which will result
in zstate disabled even though PSR is supported.
[How]
Check the supported PSR version and the PSR disable status instead.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Eric Yang <Eric.Yang2@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
There is a change previously to disallow DM to set dp drive setings when
stream is not present. The logic might not work well with DP PHY
complaince scenario with a PHY test fixture attachment. We need to make
the method allow DP link drive settings changes even without stream
attached to it.
[how]
revert back to previous code in set drive setting function then add an
empty link_resource structure, then assign link resource based on
current link resource if link resource is allocated to the current pipe.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Wayne Lin <Wayne.Lin@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
Due to bad hardware, the PHY repeater count in LTTPR cap is read as 0xFF
in some monitors while the LTTPR is actually present.
[how]
Remove PHY repeater counter check when configuring LTTPR mode.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Sung Joon Kim <sungkim@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
indirect register index/data pair may be used by multi-threads. when it
happens, it would cause register access issue that is hard to trace.
[How]
Using cgs service, which provide a sync indirect reg access api.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Roy Chan <roy.chan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why/How]
We need to handle cable capabilities for cables that support cable ID.
The cable attributes are intersected with the verified link caps to
determine appropriate max link rate. After determining cable attributes
we update the DP receiver.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: George Shen <George.Shen@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
DMCUB will hang if we send a PSR unsupported set version command.
This can occur if we fall-through into the default case in the switch
statement for PSR version.
[How]
Add an unsupported check after the switch statement.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Link encoders are created based on its engine ID. The position of a link
encoder in an array could be null since it didn't be allocated. Current
matching logic didn't consider this situation and could get null
encoder.
[How]
To add null encoder check to make the matching logic can go to next to
get a valid one.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Martin Tsai <martin.tsai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
There is a recent refactor that contains a typo to cause set throttled
vcp size skipped for dpia link. The change is to fix this typo so it won't cause
black screen
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
as we add more link_hwss we are making a generic way to determine which type
of link_hwss we should use.
Later on we may think of introduce a link policy layer. it could be a thin layer
that decide the type of link_hwss we use. So instead of passing in link and link_res
we can just pass in link_policy and swtich based on link_policy->get_link_hwss_type.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
Current we have hundreds of if/else or switch statement to check
encoder type in dc_link level. The reason is because depending
on the type of encoder dc_link needs to perform similar programming
task but with different encoder interfaces. The story is to abstract
these interfaces so dc_link can just perform the programming task
without knowing the detail of which encoder it's dealing with.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
According to the USB4 specification, FEC and DSC should be disabled
when a USB4 DPIA operates in TBT3 compatibility mode.
[How]
Upon detecting that a USB4 DPIA is connected to a device that is known
to operate in TBT3 mode, disable FEC and DSC support if they have been
reported by the TBT3 device.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Meenakshikumar Somasundaram <Meenakshikumar.Somasundaram@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
dc_link_detect_helper has multiple purpose:
1. Detect link and local sink.
2. Verify link capability by performing detection link training.
3. Start mst topology discovery and if succeeded fails the current interface.
This is difficult to maintain as item 2 has become more destructive to current
dc state. The change is to decouple these sequences to its own functions.
Eventually only item 2 is a destructive method and we will redesign this
sequence with a more unified policy across different encoder types.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Chris Park <Chris.Park@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Some architectures (e.g., ARM) throw an compilation error if the
udelay is too long. In general udelays of longer than 2000us are
not recommended on any architecture. Switch to msleep in these
cases.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Some architectures (e.g., ARM) have relatively low udelay limits.
On most architectures, anything longer than 2000us is not recommended.
Change the check to align with other similar checks in DC.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
During resume path, dpcd_set_source_specific_data is taking
extra time when core_link_write_dpcd fails on DP_SOURCE_OUI+0x03
and DP_SOURCE_MINIMUM_HBLANK_SUPPORTED. Here,aux->transfer fails
with multiple retries and consume significant amount time during
S0i3 resume.
[How]
Not to call dpcd_set_source_specific_data during resume path
when there is no oled panel connected and achieve faster resume
during S0i3.
Reviewed-by: Hersen Wu <hersenxs.wu@amd.com>
Signed-off-by: Rajib Mahapatra <rajib.mahapatra@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Unused. Convert the divisions into asserts on the divisor, to
debug why it is zero. The divide by zero is suspected of causing
kernel panics.
While I have no idea where the zero is coming from I think this
patch is a positive either way.
Cc: stable@vger.kernel.org
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
In calculate_bandwidth(), the tag free_sclk and free_yclk are reversed,
which could lead to a memory leak of yclk.
Fix this bug by changing the location of free_sclk and free_yclk.
This bug was found by a static analyzer.
Builds with 'make allyesconfig' show no new warnings,
and our static analyzer no longer warns about this code.
Fixes: 2be8989d0f ("drm/amd/display/dc/calcs/dce_calcs: Move some large variables from the stack to the heap")
Signed-off-by: Zhou Qingyang <zhou1615@umn.edu>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Some architectures (e.g., ARM) throw an compilation error if the
udelay is too long. In general udelays of longer than 2000us are
not recommended on any architecture. Switch to msleep in these
cases.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Some architectures (e.g., ARM) have relatively low udelay limits.
On most architectures, anything longer than 2000us is not recommended.
Change the check to align with other similar checks in DC.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
FIFO reset is only necessary for fast boot sequence, where otg is disabled
and dig fe is enabled when changing dispclk. Fast boot is only enabled
on embedded displays.
[How]
Change FIFO reset condition to "embedded display only".
Signed-off-by: Zhan Liu <zhan.liu@amd.com>
Reviewed-by: Charlene Liu <charlene.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
DCN301 has seamless boot enabled. With MPC split enabled
at the same time, system will hang.
[How]
Revert MPC split policy back to "MPC_SPLIT_AVOID". Since we have
ODM combine enabled on DCN301, pipe split is not necessary here.
Signed-off-by: Zhan Liu <zhan.liu@amd.com>
Reviewed-by: Charlene Liu <charlene.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
During otg sync trigger, plane states are used to decide whether the otg
is already synchronized or not. There are scenarions when otgs are
disabled without plane state getting disabled and in such case the otg is
excluded from synchronization.
[How]
Introduced pipe_idx_syncd in pipe_ctx that tracks each otgs master pipe.
When a otg is disabled/enabled, pipe_idx_syncd is reset to itself.
On sync trigger, pipe_idx_syncd is checked to decide whether a otg is
already synchronized and the otg is further included or excluded from
synchronization.
v2:
Don't drop is_blanked logic
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Reviewed-by: Mustapha Ghaddar <mustapha.ghaddar@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: meenakshikumar somasundaram <meenakshikumar.somasundaram@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Cc: torvalds@linux-foundation.org
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Pull drm fixes from Dave Airlie:
"Thanks to Daniel for taking care of things while I was out, just a set
of merge window fixes that came in this week, two i915 display fixes
and a bunch of misc amdgpu, along with a radeon regression fix.
amdgpu:
- SR-IOV fix
- VCN harvest fix
- Suspend/resume fixes
- Tahiti fix
- Enable GPU recovery on yellow carp
radeon:
- Fix error handling regression in radeon_driver_open_kms
i915:
- Update EHL display voltage swing table
- Fix programming the ADL-P display TC voltage swing"
* tag 'drm-next-2022-01-21' of git://anongit.freedesktop.org/drm/drm:
drm/radeon: fix error handling in radeon_driver_open_kms
drm/amd/amdgpu: fixing read wrong pf2vf data in SRIOV
drm/amdgpu: apply vcn harvest quirk
drm/i915/display/adlp: Implement new step in the TC voltage swing prog sequence
drm/i915/display/ehl: Update voltage swing table
drm/amd/display: Revert W/A for hard hangs on DCN20/DCN21
drm/amdgpu: drop flags check for CHIP_IP_DISCOVERY
drm/amdgpu: Fix rejecting Tahiti GPUs
drm/amdgpu: don't do resets on APUs which don't support it
drm/amdgpu: invert the logic in amdgpu_device_should_recover_gpu()
drm/amdgpu: Enable recovery on yellow carp
[Why]
FIFO reset is only necessary for fast boot sequence, where otg is disabled
and dig fe is enabled when changing dispclk. Fast boot is only enabled
on embedded displays.
[How]
Change FIFO reset condition to "embedded display only".
Signed-off-by: Zhan Liu <zhan.liu@amd.com>
Reviewed-by: Charlene Liu <charlene.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
DCN301 has seamless boot enabled. With MPC split enabled
at the same time, system will hang.
[How]
Revert MPC split policy back to "MPC_SPLIT_AVOID". Since we have
ODM combine enabled on DCN301, pipe split is not necessary here.
Signed-off-by: Zhan Liu <zhan.liu@amd.com>
Reviewed-by: Charlene Liu <charlene.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The calcs folder has FPU code on it, which should be isolated inside the
DML folder as per https://patchwork.freedesktop.org/series/93042/.
This commit aims single-handedly to correct the location of such FPU
code and does not refactor any functions.
Changes since v2:
- Corrected problems to compile when DCN was disabled.
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Isabella Basso <isabbasso@riseup.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This version brings along following fixes:
- Organize FPU associated code to DML
- Modify SMU_TIMEOUT macro
- Organize dcn201 code
- Address DS stays disabled problem under specific scenario
- Fix black screen issue
- Update DML to rev.99
- Address problem of eDP hot-plug feature
Acked-by: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: Aric Cyr <aric.cyr@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
For allow eDP hot-plug feature, the stream signal may change to VIRTUAL
when plug-out and back to eDP when plug-in. OS will still setPathMode
with same timing for each plugging, but eDP gets no stream update as we
don't check signal type changing back as keeping it VIRTUAL. It's also
unsafe for future cases that stream signal is switched with same timing.
[How]
Check stream signal type change include previous HDMI signal case.
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: Dale Zhao <dale.zhao@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
