[Why]
On some linux based OS, the hotplug->HDCP start takes longer than
4seconds (by ~100ms) This is due to the HDCP delay (3 sec) so we only
have 1 second to hotplug->stream enablement, which is not enough for
certain OS configs.
[How]
Change the Delay to 0 seconds. From testing it seems like 0 Seconds can
pass 1.x and 2.x compliances
Tested-by: Mark Broadworth <mark.broadworth@amd.com>
Reviewed-by: Aurabindo Pillai <Aurabindo.Pillai@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
reuse struct rect rather than adding a new struct.
[How]
- Userspace keeps inputting x_start, y_start, x_end, y_end
- We translate data to x, y, width, height in code flow to store
- translate back to x_start, y_start, x_end, y_end before programming HW
Tested-by: Mark Broadworth <mark.broadworth@amd.com>
Reviewed-by: Wayne Lin <Wayne.Lin@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alan Liu <HaoPing.Liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Porting secure display feature from DCN10 to DCN21. Support single
display for now and will extend to multiple displays.
[How]
- use workqueue to offload works for dmub or dmcu firmware
- after receiving ROI update from userspace, set skip_frame_cnt to 1
- refactor amdgpu_dm_crtc_handle_crc_window_irq()
- disable PSR before activating secure_display on a crtc
- check if secure_display is activated before enabling psr
- only work for single display for now.
Tested-by: Mark Broadworth <mark.broadworth@amd.com>
Reviewed-by: Wayne Lin <Wayne.Lin@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alan Liu <HaoPing.Liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm-misc-next for 6.2:
UAPI Changes:
- Documentation for page-flip flags
Cross-subsystem Changes:
- dma-buf: Add unlocked variant of vmapping and attachment-mapping
functions
Core Changes:
- atomic-helpers: CRTC primary plane test fixes
- connector: TV API consistency improvements, cmdline parsing
improvements
- crtc-helpers: Introduce drm_crtc_helper_atomic_check() helper
- edid: Fixes for HFVSDB parsing,
- fourcc: Addition of the Vivante tiled modifier
- makefile: Sort and reorganize the objects files
- mode_config: Remove fb_base from drm_mode_config_funcs
- sched: Add a module parameter to change the scheduling policy,
refcounting fix for fences
- tests: Sort the Kunit tests in the Makefile, improvements to the
DP-MST tests
- ttm: Remove unnecessary drm_mm_clean() call
Driver Changes:
- New driver: ofdrm
- Move all drivers to a common dma-buf locking convention
- bridge:
- adv7533: Remove dynamic lane switching
- it6505: Runtime PM support
- ps8640: Handle AUX defer messages
- tc358775: Drop soft-reset over I2C
- ast: Atomic Gamma LUT Support, Convert to SHMEM, various
improvements
- lcdif: Support for YUV planes
- mgag200: Fix PLL Setup on some revisions
- udl: Modesetting improvements, hot-unplug support
- vc4: Fix support for PAL-M
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20221020072405.g3o4hxuk75gmeumw@houat
This file was split in commit 5d945cbcd4
("drm/amd/display: Create a file dedicated to planes") and the logic in
dm_plane_format_mod_supported() function got changed by a switch logic.
That change broke drm_plane modifiers setting on series 5000 APUs
(tested on OXP mini AMD 5800U and HP Dev One 5850U PRO)
leading to Gamescope not working as reported on GitHub[1]
To reproduce the issue, enter a TTY and run:
$ gamescope -- vkcube
With said commit applied it will abort. This one restores the old logic,
fixing the issue that affects Gamescope.
[1](https://github.com/Plagman/gamescope/issues/624)
Cc: <stable@vger.kernel.org> # 6.0.x
Signed-off-by: Joaquín Ignacio Aramendía <samsagax@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
When using a device based on DCN32/321,
we have an issue where a second
4k@60Hz display does not light up,
and the system becomes unresponsive
for a few minutes. In the debug process,
it was possible to see a hang
in the function dcn20_post_unlock_program_front_end
in this part:
for (j = 0; j < TIMEOUT_FOR_PIPE_ENABLE_MS*1000
&& hubp->funcs->hubp_is_flip_pending(hubp); j++)
mdelay(1);
}
The hubp_is_flip_pending always returns positive
for waiting pending flips which is a symptom of
pipe hang. Additionally, the dmesg log shows
this message after a few minutes:
BUG: soft lockup - CPU#4 stuck for 26s!
...
[ +0.000003] dcn20_post_unlock_program_front_end+0x112/0x340 [amdgpu]
[ +0.000171] dc_commit_state_no_check+0x63d/0xbf0 [amdgpu]
[ +0.000155] ? dc_validate_global_state+0x358/0x3d0 [amdgpu]
[ +0.000154] dc_commit_state+0xe2/0xf0 [amdgpu]
This confirmed the hypothesis that we had a pipe
hanging somewhere. Next, after checking the
ftrace entries, we have the below weird
sequence:
[..]
2) | dcn10_lock_all_pipes [amdgpu]() {
2) 0.120 us | optc1_is_tg_enabled [amdgpu]();
2) | dcn20_pipe_control_lock [amdgpu]() {
2) | dc_dmub_srv_clear_inbox0_ack [amdgpu]() {
2) 0.121 us | amdgpu_dm_dmub_reg_write [amdgpu]();
2) 0.551 us | }
2) | dc_dmub_srv_send_inbox0_cmd [amdgpu]() {
2) 0.110 us | amdgpu_dm_dmub_reg_write [amdgpu]();
2) 0.511 us | }
2) | dc_dmub_srv_wait_for_inbox0_ack [amdgpu]() {
2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu]();
2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu]();
2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu]();
2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu]();
2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu]();
2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu]();
2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu]();
[..]
We are not expected to read from dmub register
so many times and for so long. From the trace log,
it was possible to identify that the function
dcn20_pipe_control_lock was triggering the dmub
operation when it was unnecessary and causing
the hang issue. This commit drops the unnecessary
dmub code and, consequently, fixes the second display not
lighting up the issue.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This file was split in commit 5d945cbcd4
("drm/amd/display: Create a file dedicated to planes") and the logic in
dm_plane_format_mod_supported() function got changed by a switch logic.
That change broke drm_plane modifiers setting on series 5000 APUs
(tested on OXP mini AMD 5800U and HP Dev One 5850U PRO)
leading to Gamescope not working as reported on GitHub[1]
To reproduce the issue, enter a TTY and run:
$ gamescope -- vkcube
With said commit applied it will abort. This one restores the old logic,
fixing the issue that affects Gamescope.
[1](https://github.com/Plagman/gamescope/issues/624)
Cc: <stable@vger.kernel.org> # 6.0.x
Signed-off-by: Joaquín Ignacio Aramendía <samsagax@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Read set_power_state dpcd after HPD cause USB4 CTS 4.2.1.1
[How]
Read LTTPR caps first. If aux channel not ready, wake up aux channel.
If wake up aux channel return pass, retrieve lttpr caps again. If wake
up aux channel return false, register a detection retry timer.
Tested-by: Mark Broadworth <mark.broadworth@amd.com>
Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Lewis Huang <Lewis.Huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
VPG doesn't have the ability to mute audio output by sending all 0s in
audio SDP. The existing implemention is disabling audio SDP instead.
This is same as what dp_audio_enable does. Since it is no longer
referenced by any callers, we decided to remove this interface for
simplicity.
Tested-by: Mark Broadworth <mark.broadworth@amd.com>
Reviewed-by: Charlene Liu <Charlene.Liu@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]
1. As recommended by hardware team, don't enable APG when stream is not
enabled.
2. Move audio stream encoder programming into link_hwss.
[how]
1. Merge dp_audio_enable into enable audio stream hw sequence.
2. Move stream encoder programming into link hwss level to unify stream
encoder programming interface.
Tested-by: Mark Broadworth <mark.broadworth@amd.com>
Reviewed-by: Charlene Liu <Charlene.Liu@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>
As part of the programming expectation for using DML functions, DC
requires that any DML function invoked outside DML uses:
DC_FP_START();
... dml function ...
DC_FP_END();
Additionally, all the DML functions that can be invoked outside the DML
folder call the function dc_assert_fp_enabled(), which is responsible
for triggering a warning in the case that the DML function was not
guarded by the DC_FP_START/END. For this reason, call DC_FP_START/END
inside DML is wrong, and this commit removes all of those references.
Tested-by: Mark Broadworth <mark.broadworth@amd.com>
Reviewed-by: Nevenko Stupar <Nevenko.Stupar@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The symbol is not used outside of the file, so mark it static.
Fixes the following warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_mpc.c:985:24: warning:
symbol 'dcn32_mpc_funcs' was not declared. Should it be static?
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: ruanjinjie <ruanjinjie@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The symbol is not used outside of the file, so mark it static.
Fixes the following warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_mmhubbub.c:214:28:
warning: symbol 'dcn32_mmhubbub_funcs' was
not declared. Should it be static?
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: ruanjinjie <ruanjinjie@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
These symbols qp_table_422_10bpc_min, qp_table_444_8bpc_max,
qp_table_420_12bpc_max, qp_table_444_10bpc_min, qp_table_420_8bpc_max,
qp_table_444_8bpc_min, qp_table_444_12bpc_min, qp_table_420_12bpc_min,
qp_table_422_12bpc_min, qp_table_422_12bpc_max, qp_table_444_12bpc_max,
qp_table_420_8bpc_min, qp_table_422_8bpc_min, qp_table_422_10bpc_max,
qp_table_420_10bpc_max, qp_table_420_10bpc_min, qp_table_444_10bpc_max,
qp_table_422_8bpc_max are not used outside of the file,
so mark them static.
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:28:18: warning:
symbol 'qp_table_422_10bpc_min' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:61:18: warning:
symbol 'qp_table_444_8bpc_max' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:102:18: warning:
symbol 'qp_table_420_12bpc_max' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:135:18: warning:
symbol 'qp_table_444_10bpc_min' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:188:18: warning:
symbol 'qp_table_420_8bpc_max' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:209:18: warning:
symbol 'qp_table_444_8bpc_min' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:250:18: warning:
symbol 'qp_table_444_12bpc_min' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:315:18: warning:
symbol 'qp_table_420_12bpc_min' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:348:18: warning:
symbol 'qp_table_422_12bpc_min' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:389:18: warning:
symbol 'qp_table_422_12bpc_max' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:430:18: warning:
symbol 'qp_table_444_12bpc_max' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:495:18: warning:
symbol 'qp_table_420_8bpc_min' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:516:18: warning:
symbol 'qp_table_422_8bpc_min' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:541:18: warning:
symbol 'qp_table_422_10bpc_max' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:574:16: warning:
symbol 'qp_table_420_10bpc_max' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:601:18: warning:
symbol 'qp_table_420_10bpc_min' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:628:18: warning:
symbol 'qp_table_444_10bpc_max' was not declared. Should it be static?
./drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/qp_tables.h:681:18: warning:
symbol 'qp_table_422_8bpc_max' was not declared. Should it be static?
Signed-off-by: ruanjinjie <ruanjinjie@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
When using a device based on DCN32/321,
we have an issue where a second
4k@60Hz display does not light up,
and the system becomes unresponsive
for a few minutes. In the debug process,
it was possible to see a hang
in the function dcn20_post_unlock_program_front_end
in this part:
for (j = 0; j < TIMEOUT_FOR_PIPE_ENABLE_MS*1000
&& hubp->funcs->hubp_is_flip_pending(hubp); j++)
mdelay(1);
}
The hubp_is_flip_pending always returns positive
for waiting pending flips which is a symptom of
pipe hang. Additionally, the dmesg log shows
this message after a few minutes:
BUG: soft lockup - CPU#4 stuck for 26s!
...
[ +0.000003] dcn20_post_unlock_program_front_end+0x112/0x340 [amdgpu]
[ +0.000171] dc_commit_state_no_check+0x63d/0xbf0 [amdgpu]
[ +0.000155] ? dc_validate_global_state+0x358/0x3d0 [amdgpu]
[ +0.000154] dc_commit_state+0xe2/0xf0 [amdgpu]
This confirmed the hypothesis that we had a pipe
hanging somewhere. Next, after checking the
ftrace entries, we have the below weird
sequence:
[..]
2) | dcn10_lock_all_pipes [amdgpu]() {
2) 0.120 us | optc1_is_tg_enabled [amdgpu]();
2) | dcn20_pipe_control_lock [amdgpu]() {
2) | dc_dmub_srv_clear_inbox0_ack [amdgpu]() {
2) 0.121 us | amdgpu_dm_dmub_reg_write [amdgpu]();
2) 0.551 us | }
2) | dc_dmub_srv_send_inbox0_cmd [amdgpu]() {
2) 0.110 us | amdgpu_dm_dmub_reg_write [amdgpu]();
2) 0.511 us | }
2) | dc_dmub_srv_wait_for_inbox0_ack [amdgpu]() {
2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu]();
2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu]();
2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu]();
2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu]();
2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu]();
2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu]();
2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu]();
[..]
We are not expected to read from dmub register
so many times and for so long. From the trace log,
it was possible to identify that the function
dcn20_pipe_control_lock was triggering the dmub
operation when it was unnecessary and causing
the hang issue. This commit drops the unnecessary
dmub code and, consequently, fixes the second display not
lighting up the issue.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Sub-viewport (Subvp) feature is used for changing MCLK without causing
any display artifact, requiring special treatment from the plane and
stream perspective since DC needs to read data from the cache when using
subvp. However, the function dc_commit_updates_for_stream does not
provide all the support needed by this feature which will make this
function legacy at some point. For this reason, this commit enables
dc_update_planes_and_stream for ASICs that support this feature but
preserves the old behavior for other ASICs. However,
dc_update_planes_and_stream should replace dc_commit_updates_for_stream
for all ASICs since it does most of the tasks executed by
dc_commit_updates_for_stream with other extra operations, but we need to
run tests before making this change.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Co-developed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
OTG instance is not updated in dc_commit_state_no_check for newly
committed streams because mode_change is not set. Notice that OTG update
is part of the software state, and after hardware programming, it must
be updated; for this reason, this commit updates the OTG offset right
after hardware programming.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Co-developed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
A seamless boot stream has hardware resources assigned to it, and adding
a new stream means rebuilding the current assignment. It is desirable to
avoid this situation since it may cause light-up issues on the VGA
monitor on USB-C. This commit swaps the seamless boot stream to pipe 0
(if necessary) to ensure that the pipe context matches.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Co-developed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
DC stream can be seen as a representation of the DCN backend or the data
struct that represents the center of the display pipeline. The front end
(i.e., planes) is connected to the DC stream, and in its turn, streams
are connected to the DC link. Due to this dynamic, DC must handle the
following scenarios:
1. A stream is removed;
2. A new stream is created;
3. An unchanged stream had some updates on its planes.
These combinations require that the new stream data struct become
updated and has a valid global state. For handling multiple corner cases
associated with stream operations, this commit introduces a function
dedicated to manipulating stream changes and invokes the state
validation function after that.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Co-developed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The commit stream function does not include surfaces of unaffected
streams, which may lead to some blank screens during mode change in some
edge cases. This commit adds surfaces of unaffected streams followed by
kernel-doc for documenting some of the fields that participate in this
change.
v2: squash in kerneldoc warning fix (Alex)
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Co-developed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
DC adds an instance of DML (which contains VBA) to each context, and
multiple threads might write back to the global VBA resulting in data
overwriting. To keep the consistency with other parts of the DC code,
this commit changes dc_commit_streams to copy the current DC state, and
as a result, it also changes the function signature to expect streams
instead of a context.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Co-developed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Change commit sequence will impact all ASICs. It is prudent to run this
update in small steps to keep issues under control and avoid any
potential regression. With this idea in mind, this commit is preparation
work for the complete transition to the new commit sequence. To maintain
this change manageable across multiple ASICs, this commit adds a new
function named dc_commit_streams which is a copy of the dc_commit_state
with some minor changes. Finally, inside the dc_commit_state, we check
if we are using DCN32x or above and enable the new sequence only for
those devices.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Co-developed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Context change is all about streams; for this reason, this commit
renames context_changed to streams_changed. Additionally, to make this
function more flexible, this commit changes the function signature to
receive the stream array and the stream count as a parameter.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Co-developed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The fb_base in struct drm_mode_config has been unused for a long time.
Some drivers set it and some don't leading to a very confusing state
where the variable can't be relied upon, because there's no indication
as to which driver sets it and which doesn't.
The only usage of fb_base is internal to two drivers so instead of trying
to force it into all the drivers to get it into a coherent state
completely remove it.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Thomas Zimmermann <tzimemrmann@suse.de>
Acked-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221019024401.394617-1-zack@kde.org
Building 32-bit images may fail with the following error.
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_util_32.c:
In function ‘dml32_UseMinimumDCFCLK’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_util_32.c:3142:1:
error: the frame size of 1096 bytes is larger than 1024 bytes
This is seen when building i386:allmodconfig with any of the following
compilers.
gcc (Debian 12.2.0-3) 12.2.0
gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
The problem is not seen if the compiler supports GCC_PLUGIN_LATENT_ENTROPY
because in that case CONFIG_FRAME_WARN is already set to 2048 even for
32-bit builds.
dml32_UseMinimumDCFCLK() was introduced with commit dda4fb85e4
("drm/amd/display: DML changes for DCN32/321"). It declares a large
number of local variables. Increase the frame size for the affected
file to 2048, similar to other files in the same directory, to enable
32-bit build tests with affected compilers.
Fixes: dda4fb85e4 ("drm/amd/display: DML changes for DCN32/321")
Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
Reported-by: Łukasz Bartosik <ukaszb@google.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Currently, if we encounter unimplemented functions, it is difficult to
tell what caused them just by looking at dmesg and that is compounded by
the fact that it is often hard to reproduce said issues, for instance we
have had reports of this condition being triggered when removing a
secondary display that is setup in mirror mode and is connected using
usb-c. So, to have access to more detailed debugging information, add an
ASSERT() to dal_irq_service_ack() and dal_irq_service_set() that only
triggers when we encounter an unimplemented function.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Building 32-bit images may fail with the following error.
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_util_32.c:
In function ‘dml32_UseMinimumDCFCLK’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_util_32.c:3142:1:
error: the frame size of 1096 bytes is larger than 1024 bytes
This is seen when building i386:allmodconfig with any of the following
compilers.
gcc (Debian 12.2.0-3) 12.2.0
gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
The problem is not seen if the compiler supports GCC_PLUGIN_LATENT_ENTROPY
because in that case CONFIG_FRAME_WARN is already set to 2048 even for
32-bit builds.
dml32_UseMinimumDCFCLK() was introduced with commit dda4fb85e4
("drm/amd/display: DML changes for DCN32/321"). It declares a large
number of local variables. Increase the frame size for the affected
file to 2048, similar to other files in the same directory, to enable
32-bit build tests with affected compilers.
Fixes: dda4fb85e4 ("drm/amd/display: DML changes for DCN32/321")
Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
Reported-by: Łukasz Bartosik <ukaszb@google.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
After commit 8799c0be89 ("drm/amd/display: Fix vblank refcount in vrr
transition"), a build with CONFIG_DEBUG_FS=n is broken due to a
misplaced brace, along the lines of:
In file included from drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_trace.h:39,
from drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:41:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: At top level:
./include/drm/drm_atomic.h:864:9: error: expected identifier or ‘(’ before ‘for’
864 | for ((__i) = 0; \
| ^~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8317:9: note: in expansion of macro ‘for_each_new_crtc_in_state’
8317 | for_each_new_crtc_in_state(state, crtc, new_crtc_state, j)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
Move the brace within the #ifdef so that the file can be built with or
without CONFIG_DEBUG_FS.
Fixes: 8799c0be89 ("drm/amd/display: Fix vblank refcount in vrr transition")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull more drm updates from Dave Airlie:
"Round of fixes for the merge window stuff, bunch of amdgpu and i915
changes, this should have the gcc11 warning fix, amongst other
changes.
amdgpu:
- DC mutex fix
- DC SubVP fixes
- DCN 3.2.x fixes
- DCN 3.1.x fixes
- SDMA 6.x fixes
- Enable DPIA for 3.1.4
- VRR fixes
- VRAM BO swapping fix
- Revert dirty fb helper change
- SR-IOV suspend/resume fixes
- Work around GCC array bounds check fail warning
- UMC 8.10 fixes
- Misc fixes and cleanups
i915:
- Round to closest in g4x+ HDMI clock readout
- Update MOCS table for EHL
- Fix PSR_IMR/IIR field handling
- Fix watermark calculations for gen12+/DG2 modifiers
- Reject excessive dotclocks early
- Fix revocation of non-persistent contexts
- Handle migration for dpt
- Fix display problems after resume
- Allow control over the flags when migrating
- Consider DG2_RC_CCS_CC when migrating buffers"
* tag 'drm-next-2022-10-14' of git://anongit.freedesktop.org/drm/drm: (110 commits)
drm/amd/display: Add HUBP surface flip interrupt handler
drm/i915/display: consider DG2_RC_CCS_CC when migrating buffers
drm/i915: allow control over the flags when migrating
drm/amd/display: Simplify bool conversion
drm/amd/display: fix transfer function passed to build_coefficients()
drm/amd/display: add a license to cursor_reg_cache.h
drm/amd/display: make virtual_disable_link_output static
drm/amd/display: fix indentation in dc.c
drm/amd/display: make dcn32_split_stream_for_mpc_or_odm static
drm/amd/display: fix build error on arm64
drm/amd/display: 3.2.207
drm/amd/display: Clean some DCN32 macros
drm/amdgpu: Add poison mode query for umc v8_10_0
drm/amdgpu: Update umc v8_10_0 headers
drm/amdgpu: fix coding style issue for mca notifier
drm/amdgpu: define convert_error_address for umc v8.7
drm/amdgpu: define RAS convert_error_address API
drm/amdgpu: remove check for CE in RAS error address query
drm/i915: Fix display problems after resume
drm/amd/display: fix array-bounds error in dc_stream_remove_writeback() [take 2]
...
