kernel/drivers/gpu/drm/amd/display/dc/optc, branch master

drm/amd/display: Expose functions of other dcn use

2026-02-19T17:16:10Z

[Why & HOw] Expose some functions for later dcns to reuse Reviewed-by: Charlene Liu Reviewed-by: Nicholas Kazlauskas Signed-off-by: Dmytro Laktyushkin Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Add CRC 32-bit mode support for DCN3.6+

2026-02-03T21:43:12Z

[Why] DCN 3.6+ hardware supports CRC-32 polynomial in addition to the legacy CRC-16. Enable 32-bit CRC values per color component for improvement of precision in display validation. [How] When userspace sets crc_poly_mode (0=CRC-16, 1=CRC-32) via the debugfs interface, the value is stored in dm_irq_params.crc_poly_mode. When CRC source configuration triggers amdgpu_dm_crtc_configure_crc_source(), crc_poly_mode is retrieved from dm_irq_params and passed to dc_stream_configure_crc(). In the DC layer, dc_stream_configure_crc() sets crc_poly_mode into the crc_params structure and passes it to optc35_configure_crc(). If the hardware supports the OTG_CRC_POLY_SEL register, the register is programmed to select CRC-16 or CRC-32 polynomial. When reading CRC values, optc35_get_crc() checks whether CRC32 register masks are available. If present, it reads 32-bit CRC values from OTG_CRC0/1_DATA_R32/G32/B32 registers; otherwise, it falls back to reading 16-bit CRC values from legacy OTG_CRC0/1_DATA_RG/B registers. Reviewed-by: ChiaHsuan Chung Signed-off-by: Chenyu Chen Signed-off-by: Wayne Lin Tested-by: Dan Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Add more DC HW state info to underflow logging

2025-10-28T13:57:44Z

[Why] Debugging underflow issues frequently requires knowing the HW state at the time of underflow. To enable capturing this HW state information, interface functions are needed for the various DC HW blocks. [How] This change adds the interface functions to read HW state for the following DC HW blocks: - HUBBUB - HUBP - DPP - MPC - OPP - DSC - OPTC - DCCG Reviewed-by: George Shen Signed-off-by: Karen Chen Signed-off-by: Wayne Lin Tested-by: Dan Wheeler Signed-off-by: Alex Deucher

drm/amd/display: wait for otg update pending latch before clock optimization

2025-08-27T17:57:50Z

[WHY & HOW] OTG pending update unlatched will cause system fail, wait OTG fully disabled to avoid this error. Reviewed-by: Nicholas Kazlauskas Signed-off-by: Yihan Zhu Signed-off-by: Aurabindo Pillai Tested-by: Dan Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Wait until OTG enable state is cleared

2025-08-11T15:13:21Z

[Why] Customer reported an issue that OS starts and stops device multiple times during driver installation. Frequently disabling and enabling OTG may prevent OTG from being safely disabled and cause incorrect configuration upon the next enablement. [How] Add a wait until OTG_CURRENT_MASTER_EN_STATE is cleared as a short term solution. Reviewed-by: Dillon Varone Signed-off-by: TungYu Lu Signed-off-by: Tom Chung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Constify struct timing_generator_funcs

2025-05-29T14:57:31Z

'struct timing_generator_funcs' are not modified in these drivers. Constifying these structures moves some data to a read-only section, so increases overall security, especially when the structure holds some function pointers. Signed-off-by: Christophe JAILLET Reviewed-by: Alex Hung Signed-off-by: Alex Deucher

drm/amd/display: wait for updates to latch before locking

2025-04-07T22:01:08Z

[why&how] It is possible for an update to acquire otg lock and begin programming while the previous update has not completed and its values have not latched. The correct way to go about this is to wait until the vupdate pulses so we can be sure that previous updates have latched and we can continue with the current update pipe programming, otherwise during consecutive full updates we will have corruption flash on the screen. The corruption flash occurs specifically on configs that require odm combine, and its local to a specific pipe (will not flash across whole screen). This ticket is across the otg slave, but it may also appear across master. Reviewed-by: Leo Chen Signed-off-by: Ausef Yousof Signed-off-by: Roman Li Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Refactor DCN4x and related code

2025-02-25T16:44:02Z

[why & how] Refactor existing code related to DCN4x for better code sharing with other modules. Reviewed-by: Charlene Liu Signed-off-by: Swapnil Patel Signed-off-by: Zaeem Mohamed Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Allow reuse of of DCN4x code

2025-02-13T02:03:01Z

Remove the static qualifier to make it available for code sharing with other components. Reviewed-by: Charlene Liu Signed-off-by: Dmytro Signed-off-by: Charlene Liu Signed-off-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: log destination of vertical interrupt

2025-02-13T02:02:57Z

[Why] Knowing the destination of OTG's vertical interrupt 2 is useful for debugging, but it is not currently included in the OTG state readback logic [How] Read the OTG interrupt destination register to get the vertical interrupt 2 destination on ASICs that have this register when reading back the OTG state from hardware Reviewed-by: Sung Lee Reviewed-by: Aric Cyr Signed-off-by: Josip Pavic Signed-off-by: Wayne Lin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher