summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_init.c
AgeCommit message (Collapse)AuthorFilesLines
2024-01-03drm/amd/display: Refactor INIT into component folderRevalla1-145/+0
[why] Move all init files to hwss folder. [how] moved the dcnxx_init.c and .h files into inside the hwss and cleared the linkage errors. Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Reviewed-by: Martin Leung <martin.leung@amd.com> Acked-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Revalla <hrevalla@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-10-09drm/amd/display: Refactor HWSS into component folderMounika Adhuri1-3/+3
[why] Rename hw_sequencer to hwseq. Move all hwseq files to unique folder hwss. [how] creating hwss repo in dc, and moved the dcnxx_hwseq.c and .h files into corresponding new folders inside the hwss and cleared the linkage errors by adding relative paths in the Makefile.template. Reviewed-by: Martin Leung <martin.leung@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Mounika Adhuri <moadhuri@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-10-04drm/amd/display: Adjust code style for hw_sequencer.hAurabindo Pillai1-3/+0
[Why&How] * Rearrange some definitions for consistency * Drop legacy code Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-06-09drm/amd/display: Clean FPGA code in dcQingqing Zhuo1-4/+0
[Why] Drop dead code for Linux. [How] Remove all IS_FPGA_MAXIMUS_DC and IS_DIAG_DC Reviewed-by: Ariel Bernstein <eric.bernstein@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-06-09drm/amd/display: Add visual confirm color support for MCLK switchLeo (Hanghong) Ma1-1/+1
[Why && How] We would like to have visual confirm color support for MCLK switch. 1. Set visual confirm color to yellow: Vblank MCLK switch. 2. Set visual confirm color to cyan: FPO + Vblank MCLK switch. 3. Set visual confirm color to pink: Vactive MCLK switch. Reviewed-by: Jun Lei <jun.lei@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Leo (Hanghong) Ma <hanghong.ma@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-19drm/amd/display: rework recent update PHY state commitWenjing Liu1-0/+4
[why] Original change 594b237b9a07 ("drm/amd/display: Add interface to track PHY state") was implemented by assuming stream's dpms off is equivalent to PHY power off. This assumption doesn't hold in following situations: 1. MST multiple stream scenario, where multiple streams are sharing the same PHY output. Toggle dpms off for one of the stream doesn't power off the PHY due to the presence of other streams. 2. enable stream failure scenario, where enable stream fails due to failure of link training. This will cause DPMS off is set to false, while the actual PHY power state is off in certain cases. Due to the problematic assumption, the logic will skip disabling other streams for MST multiple stream scenario, therefore PHY is not actually powered off. [how] 1. Rework this refactor by moving PHY state update down to hardware level, where we update PHY state in place when hardware sequencer is actually changing the power state of the PHY hardware. 2. Reimplement symclk on TX off workaround in place when we are actually calling transmitter control to power off PHY in dcn32. Note the workaround is added due to the lack of proper software interface to set TX while keeping symclk on. We plan to address this interface problem so we can set TX off only without affecting symclk in future dcn versions. Fixes: 594b237b9a07 ("drm/amd/display: Add interface to track PHY state") 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> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-12-13drm/amd: append missing includesIsabella Basso1-0/+2
This fixes warnings caused by global functions lacking prototypes:, such as: warning: no previous prototype for 'dcn303_hw_sequencer_construct' [-Wmissing-prototypes] 12 | void dcn303_hw_sequencer_construct(struct dc *dc) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... warning: no previous prototype for ‘amdgpu_has_atpx’ [-Wmissing-prototypes] 76 | bool amdgpu_has_atpx(void) { | ^~~~~~~~~~~~~~~ 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>
2021-06-08drm/amd/display: Refactor visual confirmWyatt Wood1-2/+1
[Why + How] Visual confirm has no asic-specific logic, so we can refactor and unify these functions that are currently spread out across multiple dcn files. Add a new hw sequencer interface update_visual_confirm_color, and a new mpc function pointer set_bg_color. This will allow visual confirm to updated independently of MPCC blending updates. v2: squash in DCN3.1 fixes Signed-off-by: Wyatt Wood <wyatt.wood@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Stylon Wang <stylon.wang@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-27Revert "drm/amd/display: Refactor and add visual confirm for HW Flip Queue"Qingqing Zhuo1-1/+0
This reverts commit 3ca402375a2197579d1029e7fa9d856847fe0e7b. Recent visual confirm changes are regressing the driver, causing a black screen on boot in some green sardine configs, or visual confirm is not updated at all. Signed-off-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-19drm/amd/display: Refactor and add visual confirm for HW Flip QueueWyatt Wood1-0/+1
[Why] Visual confirm will indicate if driver is programming the surface address. Refactor is required because much of the visual confirm logic is buried deep in the mpcc files. In addition, visual confirm is not updated during fast updates. [How] In order to have visual confirm for driver flips, visual confirm needs to be updated on every frame, including fast updates. Add a new hw sequencer interface update_visual_confirm_color, and a new mpc function pointer set_bg_color. v2: drop unused variable (Alex) Signed-off-by: Wyatt Wood <wyatt.wood@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Stylon Wang <stylon.wang@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-04-09drm/amd/display: Add function and debugfs to dump DCC_EN bitVictor Lu1-0/+1
[why] Currently to view the DCC_EN bit the entire DTN log must be dumped. A compact method to view the DCC_EN bit is desirable. [how] Introduce new debugfs interface that only dumps the DCC_EN bit. Example usage: cat /sys/kernel/debug/dri/0/amdgpu_dm_dcc_en Signed-off-by: Victor Lu <victorchengchi.lu@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-02-22drm/amd/display: Synchronize displays with different timingsVladimir Stempen1-0/+1
[why] Vendor based fan noise improvement [how] Report timing synchronizable when DP streams time frame difference is less than 0.05 percent. Adjust DP DTOs and sync displays using MASTER_UPDATE_LOCK_DB_X_Y Signed-off-by: Vladimir Stempen <vladimir.stempen@amd.com> Acked-by: Bindu Ramamurthy <bindu.r@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-02-18drm/amd/display: Old sequence for HUBP blankAurabindo Pillai1-1/+0
New proposed sequence for HUBP blanking causes regressions where the hardware would fail to enter blank which triggers an assert in the new sequence. This change brings back the old sequence. Fixes: 985faf2c4ecb60 ("drm/amd/display: New sequence for HUBP blank") Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-13drm/amd/display: New sequence for HUBP blankWesley Chalmers1-0/+1
[WHY] DCN30 has a bug where blanking HUBP blocks pstate allow unless HUBP_DISABLE is toggled afterwards. [HOW] Create a HW sequence for blanking HUBP. 1. Wait for enter VBLANK 2. Set HUBP_BLANK 3. Make sure HUBP_IN_BLANK = 1 4. Toggle HUBP_DISABLE on and off to perform soft reset All existing calls to hubp->funcs->set_blank should be replaced with this new sequence. In wait_for_mpcc_disconnect, only blank the pipe being disconnected, and leave all other pipes unmodified. Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Wesley Chalmers <Wesley.Chalmers@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-11-02drm/amd/display: Blank HUBP during pixel data blank for DCN30 v2Joshua Aberback1-0/+1
[Why] Prior commit "Blank HUBP during pixel data blank for DCN30" missed the call to set_disp_pattern_generator from set_crtc_test_pattern, which re-exposed the issue for which we initially blocked active-only p-state switching. [How] - remove dcn30_blank_pixel_data, set dcn30 back to dcn20 version - new hwss funciton set_disp_pattern_generator - dcn20 version just calls opp_set_disp_pattern_generator - dcn30 version implements the HUBP blank Signed-off-by: Joshua Aberback <joshua.aberback@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-26drm/amd/display: Update GSL state if leaving immediate flipAlvin Lee1-1/+0
[Why] We should leave GSL if we're not doing immediate flip no matter if we're doing pipe split or not [How] Check for updating GSL state whenever we're not doing immediate flip v2: Squash in build fix (Alex) Signed-off-by: Aric Cyr <aric.cyr@amd.com> Signed-off-by: Alvin Lee <alvin.lee2@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-09-22drm/amd/display: eDP intermittent black screen during PnPPeikang Zhang1-0/+1
[Why] We dont's turn off backlight before power off eDP (VDD), which is a violation of eDP specs. [How] Power off eDP backlight before power off eDP Signed-off-by: Peikang Zhang <peikang.zhang@amd.com> Reviewed-by: Anthony Koo <Anthony.Koo@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-08-10drm/amd/display: Disconnect pipe separetely when disable pipe splitAlvin Lee1-0/+2
[Why] When changing pixel formats for HDR (e.g. ARGB -> FP16) there are configurations that change from 2 pipes to 1 pipe. In these cases, it seems that disconnecting MPCC and doing a surface update at the same time(after unlocking) causes some registers to be updated slightly faster than others after unlocking (e.g. if the pixel format is updated to FP16 before the new surface address is programmed, we get corruption on the screen because the pixel formats aren't matching). We separate disconnecting MPCC from the rest of the pipe programming sequence to prevent this. [How] Move MPCC disconnect into separate operation than the rest of the pipe programming. Signed-off-by: Alvin Lee <alvin.lee2@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-08-10drm/amd/display: Revert regressionAlvin Lee1-2/+0
[Why] Caused pipe split regression Signed-off-by: Alvin Lee <alvin.lee2@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-08-04drm/amd/display: Separate pipe disconnect from rest of progrmamingAlvin Lee1-0/+2
[Why] When changing pixel formats for HDR (e.g. ARGB -> FP16) there are configurations that change from 2 pipes to 1 pipe. In these cases, it seems that disconnecting MPCC and doing a surface update at the same time(after unlocking) causes some registers to be updated slightly faster than others after unlocking (e.g. if the pixel format is updated to FP16 before the new surface address is programmed, we get corruption on the screen because the pixel formats aren't matching). We separate disconnecting MPCC from the rest of the pipe programming sequence to prevent this. [How] Move MPCC disconnect into separate operation than the rest of the pipe programming. Signed-off-by: Alvin Lee <alvin.lee2@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-30drm/amd/display: Allow asic specific FSFT timing optimizationReza Amini1-0/+3
[Why] Each asic can optimize best based on its capabilities [How] Optimizing timing for a new pixel clock Signed-off-by: Reza Amini <Reza.Amini@amd.com> Reviewed-by: Anthony Koo <Anthony.Koo@amd.com> Acked-by: Eryk Brol <eryk.brol@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-14drm/amd/display: Power down hardware if set mode is not called before timeoutSung Lee1-0/+1
[WHY] In headless systems, if set mode is not called, hardware will not be powered down on boot, causing HW/SW discrepancies. Powering down hardware on boot will ensure SW state is accurate. [HOW] Set a timer callback on boot for 10 seconds. If set mode is not called within that time, power down hardware. Otherwise, do not power down. 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>
2020-05-28drm/amd/display: Implement some asic specific abm call backs.Yongqiang Sun1-0/+1
[Why & How] Implement abm set_pipe call stacks Have some asics speicifc call stacks for abm. Signed-off-by: Yongqiang Sun <yongqiang.sun@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>
2020-05-21drm/amd/display: Defer cursor lock until after VUPDATENicholas Kazlauskas1-0/+1
[Why] We dropped the delay after changed the cursor functions locking the entire pipe to locking just the CURSOR registers to fix page flip stuttering - this introduced cursor stuttering instead, and an underflow issue. The cursor update can be delayed indefinitely if the cursor update repeatedly happens right around VUPDATE. The underflow issue can happen if we do a viewport update on a pipe on the same frame where a cursor update happens around VUPDATE - the old cursor registers are retained which can be in an invalid position. This can cause a pipe hang and indefinite underflow. [How] The complex, ideal solution to the problem would be a software triple buffering mechanism from the DM layer to program only one cursor update per frame just before VUPDATE. The simple workaround until we have that infrastructure in place is this change - bring back the delay until VUPDATE before locking, but with some corrections to the calculations. This didn't work for all timings before because the calculation for VUPDATE was wrong - it was using the offset from VSTARTUP instead and didn't correctly handle the case where VUPDATE could be in the back porch. Add a new hardware sequencer function to use the existing helper to calculate the real VUPDATE start and VUPDATE end - VUPDATE can last multiple lines after all. Change the udelay to incorporate the width of VUPDATE as well. 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>
2020-05-05drm/amd/display: Move panel_cntl specific register from abm to panel_cntl.Yongqiang Sun1-0/+1
[Why] panel_cntl specific register should be access in panel_cntl object. [How] Move these register access from abm to panel_cntl. Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by: Anthony Koo <Anthony.Koo@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-04-28drm/amd/display: Use cursor locking to prevent flip delaysAric Cyr1-0/+1
[Why] Current locking scheme for cursor can result in a flip missing its vsync, deferring it for one or more vsyncs. Result is a potential for stuttering when cursor is moved. [How] Use cursor update lock so that flips are not blocked while cursor is being programmed. Signed-off-by: Aric Cyr <aric.cyr@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-04-28drm/amd/display: Add set backlight to hw sequencer.Yongqiang Sun1-0/+1
[Why & How] Add set backlight to hw sequencer, dmu communication will be handled in hw sequencer for new asics. Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by: Anthony Koo <Anthony.Koo@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-04-22drm/amd/display: move panel power seq to new panel structAnthony Koo1-2/+0
[Why] panel power sequencer is currently just sitting in hwseq but it really it tied to internal panels [How] make a new panel struct to contain power sequencer code Signed-off-by: Anthony Koo <Anthony.Koo@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>
2020-03-13drm/amd/display: fix typos for dcn20_funcs and dcn21_funcs structStanley.Yang1-1/+0
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>
2020-02-25drm/amd/display: Add function pointers for panel related hw functionsAnthony Koo1-0/+2
[Why] Make panel backlight and power on/off functions into hardware specific function pointers [How] Add function pointers for panel related hw functions - is_panel_powered_on - is_panel_backlight_on Signed-off-by: Anthony Koo <Anthony.Koo@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-02-06drm/amd/display: Added locking for atomic update stream and update planesAnthony Koo1-1/+1
[Why] Screen flickering when HDR switches between FP16 and ARGB2101010 [How] Moved pipe_control_lock so stream update and plane update occur atomically Signed-off-by: Anthony Koo <Anthony.Koo@amd.com> Signed-off-by: Lucy Li <lucy.li@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>
2020-02-06drm/amd/display: Split program front end part that occur outside lockAnthony Koo1-0/+1
[Why] Eventually want to lock at a higher level in stack. To do this, we need to be able to isolate the parts that need to be done after pipe unlock. [How] Split out programming that is done post unlock. 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>
2019-12-05drm/amd/display: add separate of private hwss functionsAnthony Koo1-24/+30
[Why] Some function pointers in the hwss function pointer table are meant to be hw sequencer entry points to be called from dc. However some of those function pointers are not meant to be entry points, but instead used as a code reuse/inheritance tool called directly by other hwss functions, not by dc. Therefore, we want a more clear separation of which functions we determine to be interface functions vs the functions we use within hwss. [How] DC interface functions will be stored in: struct hw_sequencer_funcs Functions used within HWSS will be stored in: struct hwseq_private_funcs Signed-off-by: Anthony Koo <Anthony.Koo@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>
2019-11-19drm/amd/display: cleanup of function pointer tablesAnthony Koo1-0/+127
[Why] It is becoming increasingly hard to figure out which function is called on the different DCN versions [How] 1. Make function pointer table init in its own init.c file 2. Remove other scenarios in hwseq.c file that need to include headers of other DCN versions. (If needed, it should have been done via the function pointers) Signed-off-by: Anthony Koo <Anthony.Koo@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>