kernel/linux.git/drivers/gpu/drm/amd/display/dc/inc, branch v6.4

drm/amd/display: On clock init, maintain DISPCLK freq

2023-04-11T22:03:35+00:00

[Description] - On init if a display is connected, we need to maintain the DISPCLK frequency - Even though DPG_EN=1, the display still requires the correct timing or it could cause audio corruption (if DISPCLK freq is reduced) - Read the current DISPCLK freq and request the same value to ensure the timing is valid and unchanged - However, add option to do a full pipe power down (including link) which will also avoid audio related issues - Disabled for the time being on dcn32 Reviewed-by: Jun Lei Acked-by: Qingqing Zhuo Signed-off-by: Alvin Lee Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Use per pipe P-State force for FPO

2023-03-31T15:18:54+00:00

[Description] * Pass in pipe index for FPO cmd to DMCUB - This change will pass in the pipe index for each stream that is using FPO - This change is in preparation to enable FPO + VActive * Use per pipe P-State force for FPO - For FPO, instead of using max watermarks value for P-State disallow, use per pipe p-state force instead - This is in preparation to enable FPO + VActive Reviewed-by: Jun Lei Acked-by: Qingqing Zhuo Signed-off-by: Alvin Lee Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Fix 4to1 MPC black screen with DPP RCO

2023-03-31T15:18:54+00:00

[Why] DPP Root clock optimization when combined with 4to1 MPC combine results in the screen turning black. This is because the DPPCLK is stopped during the middle of an optimize_bandwidth sequence during commit_minimal_transition without going through plane power down/power up. [How] The intent of a 0Hz DPP clock through update_clocks is to disable the DTO. This differs from the behavior of stopping the DPPCLK entirely (utilizing a 0Hz clock on some ASIC) so it's better to move this logic to reside next to plane power up/power down where we gate the HUBP/DPP DOMAIN. The new sequence should be: Power down: PG enabled -> RCO on Power up: RCO off -> PG disabled Rename power_on_plane to power_on_plane_resources to reflect the actual operation that's occurring. Cc: stable@vger.kernel.org Cc: Mario Limonciello Reviewed-by: Jun Lei Acked-by: Qingqing Zhuo Signed-off-by: Nicholas Kazlauskas Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Add function pointer for validate bw usb4

2023-03-22T04:59:45+00:00

[WHY] In order to follow the new protocol of calling link functions [HOW] Add the function pointer to the link_srv Reviewed-by: Kshitij Bhardwaj Acked-by: Qingqing Zhuo Signed-off-by: Mustapha Ghaddar Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: convert link.h functions to function pointer style

2023-03-14T19:35:03+00:00

[Why & How] All dc subcomponents should call another dc component via function pointers stored in a component structure. This is part of dc coding convention since the beginning. The reason behind this is to improve encapsulation and polymorphism. The function contract is extracted into a single link service structure defined in link.h header file and implemented only in link_factory.c instead of spreading across multiple files in link component file structure. Reviewed-by: Jun Lei Acked-by: Qingqing Zhuo Signed-off-by: Wenjing Liu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Rename DCN config to FP

2023-03-07T19:22:40+00:00

[Why & How] The only reason we have the DCN config is for floating point support. Rename it to make that clear and (hopefully) avoid misuse of the config in the future. Reviewed-by: Rodrigo Siqueira Acked-by: Qingqing Zhuo Signed-off-by: Harry Wentland Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Drop unnecessary DCN guards

2023-03-07T19:22:40+00:00

[Why & How] DC is littered with many DCN guards that are not needed. Drop them. Reviewed-by: Rodrigo Siqueira Acked-by: Qingqing Zhuo Signed-off-by: Harry Wentland Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: move dc_link functions in protocols folder to dc_link_exports

2023-03-07T19:22:40+00:00

[why] link component should only have one interface serving dc. [how] We are moving dc_link functions exposed to DM to dc_link_exports and unify link component interface in link.h with function pointer to match the style of other dc component. This is the third step to move dc_link functions under protocols folder to dc_link_exports. Reviewed-by: Jun Lei Acked-by: Qingqing Zhuo Signed-off-by: Wenjing Liu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: move dc_link functions in link root folder to dc_link_exports

2023-03-07T19:22:40+00:00

[why] link component should only have one interface serving dc. [how] We are moving dc_link functions exposed to DM to dc_link_exports and unify link component interface in link.h with function pointer to match the style of other dc component. This is the second step to move dc_link functions under link root folder to dc_link_exports. Reviewed-by: Jun Lei Acked-by: Qingqing Zhuo Signed-off-by: Wenjing Liu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: move dc_link functions in accessories folder to dc_link_exports

2023-03-07T19:22:40+00:00

[why] link component should only have one interface serving dc. [how] We are moving dc_link functions exposed to DM to dc_link_exports and unify link component interface in link.h with function pointer to match the style of other dc component. This is the first step to move dc_link functions under accessories folder to dc_link_exports. Reviewed-by: Jun Lei Acked-by: Qingqing Zhuo Signed-off-by: Wenjing Liu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher