|
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3, v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5, v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11, v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4, v6.11-rc3, v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6 |
|
| #
5ed9481d |
| 26-Jun-2024 |
Mounika Adhuri <[email protected]> |
drm/amd/display: Refactoring MPC
[Why] To refactor MPC files
[How] Moved MPC files to respective folders and updated makefiles appropriately.
Reviewed-by: Martin Leung <[email protected]> Signe
drm/amd/display: Refactoring MPC
[Why] To refactor MPC files
[How] Moved MPC files to respective folders and updated makefiles appropriately.
Reviewed-by: Martin Leung <[email protected]> Signed-off-by: Jerry Zuo <[email protected]> Signed-off-by: Mounika Adhuri <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|
| #
906fd46a |
| 02-Jul-2024 |
Revalla Hari Krishna <[email protected]> |
drm/amd/display: Refactoring MMHUBBUB
[Why] To refactor MMHUBBUB files
[How] Moved mmhubbub files from dcn20 to /mmhubbub/ folder and update makefile to fix compilation.
Reviewed-by: Martin Leung
drm/amd/display: Refactoring MMHUBBUB
[Why] To refactor MMHUBBUB files
[How] Moved mmhubbub files from dcn20 to /mmhubbub/ folder and update makefile to fix compilation.
Reviewed-by: Martin Leung <[email protected]> Signed-off-by: Jerry Zuo <[email protected]> Signed-off-by: Revalla Hari Krishna <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|
| #
f60881ca |
| 26-Jun-2024 |
Revalla Hari Krishna <[email protected]> |
drm/amd/display: Refactoring OPP
[Why] To refactor OPP files
[How] Moved opp related files to specific opp folder and updated Makefiles.
Acked-by: Rodrigo Siqueira <[email protected]> Signe
drm/amd/display: Refactoring OPP
[Why] To refactor OPP files
[How] Moved opp related files to specific opp folder and updated Makefiles.
Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Jerry Zuo <[email protected]> Signed-off-by: Revalla Hari Krishna <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|
|
Revision tags: v6.10-rc5 |
|
| #
d19deabe |
| 20-Jun-2024 |
Bhuvanachandra Pinninti <[email protected]> |
drm/amd/display: Move dio files into dio folder
[why] Refactor the code of dio to unit test.
[how] Moved files to respective folders and changed cMakeLists and makefiles.
Acked-by: Rodrigo Siqueir
drm/amd/display: Move dio files into dio folder
[why] Refactor the code of dio to unit test.
[how] Moved files to respective folders and changed cMakeLists and makefiles.
Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Jerry Zuo <[email protected]> Signed-off-by: Bhuvanachandra Pinninti <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|
|
Revision tags: v6.10-rc4, v6.10-rc3, v6.10-rc2, v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6 |
|
| #
0cfdfebe |
| 25-Apr-2024 |
Bhuvana Chandra Pinninti <[email protected]> |
drm/amd/display: Refactor HUBP into component folder.
[why] cleaning up the code refactor requires hubp to be in its own component.
[how] move all files under newly created hubp folder and fixing t
drm/amd/display: Refactor HUBP into component folder.
[why] cleaning up the code refactor requires hubp to be in its own component.
[how] move all files under newly created hubp folder and fixing the makefiles.
Reviewed-by: Martin Leung <[email protected]> Acked-by: Tom Chung <[email protected]> Signed-off-by: Bhuvana Chandra Pinninti <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|
| #
0a8d2528 |
| 22-Apr-2024 |
Revalla Hari Krishna <[email protected]> |
drm/amd/display: Refactor DCCG into component folder
[why] cleaning up the code refactor requires dccg to be in its own component.
[how] move all files under newly created dccg folder and fixing th
drm/amd/display: Refactor DCCG into component folder
[why] cleaning up the code refactor requires dccg to be in its own component.
[how] move all files under newly created dccg folder and fixing the makefiles.
Reviewed-by: Martin Leung <[email protected]> Acked-by: Tom Chung <[email protected]> Signed-off-by: Revalla Hari Krishna <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|
| #
f5d75327 |
| 22-Apr-2024 |
Leo Ma <[email protected]> |
drm/amd/display: Fix invalid Copyright notice
[Why && How] Copyright notice failed in the Palamida scan and make changes to align with our guidelines.
Acked-by: Tom Chung <[email protected]>
drm/amd/display: Fix invalid Copyright notice
[Why && How] Copyright notice failed in the Palamida scan and make changes to align with our guidelines.
Acked-by: Tom Chung <[email protected]> Signed-off-by: Leo Ma <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|
|
Revision tags: v6.9-rc5 |
|
| #
f9c7818c |
| 18-Apr-2024 |
Revalla Hari Krishna <[email protected]> |
drm/amd/display: Refactor HUBBUB into component folder
[why] cleaning up the code refactor requires hubbub to be in its own component.
[how] Move all files under newly created hubbub folder and fix
drm/amd/display: Refactor HUBBUB into component folder
[why] cleaning up the code refactor requires hubbub to be in its own component.
[how] Move all files under newly created hubbub folder and fix the makefiles.
Reviewed-by: Martin Leung <[email protected]> Acked-by: Wayne Lin <[email protected]> Signed-off-by: Revalla Hari Krishna <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|
|
Revision tags: v6.9-rc4, v6.9-rc3, v6.9-rc2, v6.9-rc1, v6.8, v6.8-rc7, v6.8-rc6, v6.8-rc5 |
|
| #
88867807 |
| 15-Feb-2024 |
Revalla Hari Krishna <[email protected]> |
drm/amd/display: Refactor DPP into a component directory
[WHY & HOW] Move all dpp files to a new dpp directory.
Reviewed-by: Martin Leung <[email protected]> Acked-by: Alex Hung <[email protected]
drm/amd/display: Refactor DPP into a component directory
[WHY & HOW] Move all dpp files to a new dpp directory.
Reviewed-by: Martin Leung <[email protected]> Acked-by: Alex Hung <[email protected]> Signed-off-by: Revalla Hari Krishna <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|
|
Revision tags: v6.8-rc4, v6.8-rc3, v6.8-rc2, v6.8-rc1, v6.7, v6.7-rc8, v6.7-rc7, v6.7-rc6 |
|
| #
f6154d8b |
| 13-Dec-2023 |
Revalla <[email protected]> |
drm/amd/display: Refactor INIT into component folder
[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
drm/amd/display: Refactor INIT into component folder
[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 <[email protected]> Reviewed-by: Martin Leung <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Revalla <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|
|
Revision tags: v6.7-rc5, v6.7-rc4, v6.7-rc3, v6.7-rc2, v6.7-rc1 |
|
| #
3d0fe494 |
| 09-Nov-2023 |
Parandhaman K <[email protected]> |
drm/amd/display: Refactor OPTC into component folder
[why] Move all optc files to unique folder optc.
[how] creating optc repo in dc, and moved the dcnxx_optc.c and .h files into corresponding new
drm/amd/display: Refactor OPTC into component folder
[why] Move all optc files to unique folder optc.
[how] creating optc repo in dc, and moved the dcnxx_optc.c and .h files into corresponding new folders inside the optc and cleared the linkage errors by adding relative paths in the Makefile.template.
Reviewed-by: Martin Leung <[email protected]> Acked-by: Hamza Mahfooz <[email protected]> Signed-off-by: Parandhaman K <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|
|
Revision tags: v6.6, v6.6-rc7 |
|
| #
6c22fb07 |
| 18-Oct-2023 |
Bhuvana Chandra Pinninti <[email protected]> |
drm/amd/display: Refactor DSC into component folder
[why]
To refactor DSC and make DSC files unit testable.
[how]
moved the dcnxx_dsc.c and .h files into corresponding dcn folders inside the dsc
drm/amd/display: Refactor DSC into component folder
[why]
To refactor DSC and make DSC files unit testable.
[how]
moved the dcnxx_dsc.c and .h files into corresponding dcn folders inside the dsc and cleared the linkage errors.
Reviewed-by: Wenjing Liu <[email protected]> Acked-by: Hamza Mahfooz <[email protected]> Signed-off-by: Bhuvana Chandra Pinninti <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|
|
Revision tags: v6.6-rc6, v6.6-rc5 |
|
| #
8b8eed05 |
| 06-Oct-2023 |
Mounika Adhuri <[email protected]> |
drm/amd/display: Refactor resource into component directory
[WHY] Move all resource files to unique folder resource.
[HOW] Created resource folder in dc, moved the dcnxx_resource.c and dcnxx_resour
drm/amd/display: Refactor resource into component directory
[WHY] Move all resource files to unique folder resource.
[HOW] Created resource folder in dc, moved the dcnxx_resource.c and dcnxx_resource.h files into corresponding new folders inside the resource and made appropriate changes for compilation in Makefiles.
Reviewed-by: Martin Leung <[email protected]> Acked-by: Alex Hung <[email protected]> Signed-off-by: Mounika Adhuri <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|
|
Revision tags: v6.6-rc4, v6.6-rc3 |
|
| #
e53524cd |
| 22-Sep-2023 |
Mounika Adhuri <[email protected]> |
drm/amd/display: Refactor HWSS into component folder
[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
drm/amd/display: Refactor HWSS into component folder
[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 <[email protected]> Acked-by: Tom Chung <[email protected]> Signed-off-by: Mounika Adhuri <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|
|
Revision tags: v6.6-rc2, v6.6-rc1, v6.5, v6.5-rc7, v6.5-rc6, v6.5-rc5, v6.5-rc4, v6.5-rc3, v6.5-rc2, v6.5-rc1, v6.4, v6.4-rc7, v6.4-rc6, v6.4-rc5, v6.4-rc4, v6.4-rc3, v6.4-rc2, v6.4-rc1, v6.3, v6.3-rc7, v6.3-rc6, v6.3-rc5, v6.3-rc4, v6.3-rc3, v6.3-rc2, v6.3-rc1, v6.2, v6.2-rc8, v6.2-rc7, v6.2-rc6, v6.2-rc5, v6.2-rc4, v6.2-rc3, v6.2-rc2, v6.2-rc1, v6.1, v6.1-rc8, v6.1-rc7, v6.1-rc6, v6.1-rc5, v6.1-rc4, v6.1-rc3, v6.1-rc2, v6.1-rc1, v6.0, v6.0-rc7, v6.0-rc6, v6.0-rc5, v6.0-rc4, v6.0-rc3, v6.0-rc2, v6.0-rc1, v5.19, v5.19-rc8, v5.19-rc7, v5.19-rc6, v5.19-rc5, v5.19-rc4, v5.19-rc3, v5.19-rc2, v5.19-rc1, v5.18, v5.18-rc7, v5.18-rc6, v5.18-rc5, v5.18-rc4, v5.18-rc3, v5.18-rc2, v5.18-rc1, v5.17, v5.17-rc8, v5.17-rc7, v5.17-rc6 |
|
| #
cf689e86 |
| 23-Feb-2022 |
Melissa Wen <[email protected]> |
drm/amd/display: move FPU-related code from dcn20 to dml folder
Move parts of dcn20 code that uses FPU to dml folder. It aims to isolate FPU operations as described by series:
drm/amd/display: Intr
drm/amd/display: move FPU-related code from dcn20 to dml folder
Move parts of dcn20 code that uses FPU to dml folder. It aims to isolate FPU operations as described by series:
drm/amd/display: Introduce FPU directory inside DC https://patchwork.freedesktop.org/series/93042/
This patch moves the following functions from dcn20_resource to dml/dcn20_fpu and calls of public functions in dcn20_resource are wrapped by DC_FP_START/END():
- void dcn20_populate_dml_writeback_from_context - static bool is_dtbclk_required() - static enum dcn_zstate_support_state() - void dcn20_calculate_dlg_params() - static void swizzle_to_dml_params() - int dcn20_populate_dml_pipes_from_context() - void dcn20_calculate_wm() - void dcn20_cap_soc_clocks() - void dcn20_update_bounding_box() - void dcn20_patch_bounding_box() - bool dcn20_validate_bandwidth_fp()
This movement also affects dcn21/30/31, as dcn20_calculate_dlg_params() is used by them. For this reason, I included dcn20_fpu headers in dcn20_resource headers to make dcn20_calculate_dlg_params() visible to dcn21/30/31.
Three new functions are created to isolate well-delimited FPU operations:
- void dcn20_fpu_set_wb_arb_params(): set cli_watermark, pstate_watermark and time_per_pixel from wb_arb_params (struct mcif_arb_params), since those uses FPU operations on double types: WritebackUrgentWatermark, WritebackDRAMClockChangeWatermark, '16.0'. - void dcn20_fpu_set_wm_ranges(): set min_fill_clk_mhz and max_fill_clk_mhz involves FPU calcs on dram_speed_mts (double type); - void dcn20_fpu_adjust_dppclk(): adjust operation on RequiredDPPCLK that is a double.
Signed-off-by: Melissa Wen <[email protected]> Acked-by: Alan Liu <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|
|
Revision tags: v5.17-rc5, v5.17-rc4, v5.17-rc3, v5.17-rc2, v5.17-rc1, v5.16, v5.16-rc8, v5.16-rc7, v5.16-rc6, v5.16-rc5, v5.16-rc4, v5.16-rc3, v5.16-rc2, v5.16-rc1, v5.15, v5.15-rc7, v5.15-rc6, v5.15-rc5, v5.15-rc4, v5.15-rc3, v5.15-rc2, v5.15-rc1, v5.14, v5.14-rc7, v5.14-rc6, v5.14-rc5, v5.14-rc4, v5.14-rc3, v5.14-rc2, v5.14-rc1, v5.13, v5.13-rc7, v5.13-rc6, v5.13-rc5, v5.13-rc4, v5.13-rc3, v5.13-rc2, v5.13-rc1, v5.12, v5.12-rc8, v5.12-rc7, v5.12-rc6, v5.12-rc5, v5.12-rc4, v5.12-rc3, v5.12-rc2, v5.12-rc1, v5.12-rc1-dontuse, v5.11, v5.11-rc7, v5.11-rc6, v5.11-rc5, v5.11-rc4, v5.11-rc3 |
|
| #
c241ed2f |
| 04-Jan-2021 |
Alex Deucher <[email protected]> |
drm/amdgpu/display: drop DCN support for aarch64
From Ard:
"Simply disabling -mgeneral-regs-only left and right is risky, given that the standard AArch64 ABI permits the use of FP/SIMD registers an
drm/amdgpu/display: drop DCN support for aarch64
From Ard:
"Simply disabling -mgeneral-regs-only left and right is risky, given that the standard AArch64 ABI permits the use of FP/SIMD registers anywhere, and GCC is known to use SIMD registers for spilling, and may invent other uses of the FP/SIMD register file that have nothing to do with the floating point code in question. Note that putting kernel_neon_begin() and kernel_neon_end() around the code that does use FP is not sufficient here, the problem is in all the other code that may be emitted with references to SIMD registers in it.
So the only way to do this properly is to put all floating point code in a separate compilation unit, and only compile that unit with -mgeneral-regs-only."
Disable support until the code can be properly refactored to support this properly on aarch64.
Acked-by: Will Deacon <[email protected]> Reported-by: Ard Biesheuvel <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|
| #
88d5cb25 |
| 04-Jan-2021 |
Alex Deucher <[email protected]> |
drm/amdgpu/display: drop DCN support for aarch64
From Ard:
"Simply disabling -mgeneral-regs-only left and right is risky, given that the standard AArch64 ABI permits the use of FP/SIMD registers an
drm/amdgpu/display: drop DCN support for aarch64
From Ard:
"Simply disabling -mgeneral-regs-only left and right is risky, given that the standard AArch64 ABI permits the use of FP/SIMD registers anywhere, and GCC is known to use SIMD registers for spilling, and may invent other uses of the FP/SIMD register file that have nothing to do with the floating point code in question. Note that putting kernel_neon_begin() and kernel_neon_end() around the code that does use FP is not sufficient here, the problem is in all the other code that may be emitted with references to SIMD registers in it.
So the only way to do this properly is to put all floating point code in a separate compilation unit, and only compile that unit with -mgeneral-regs-only."
Disable support until the code can be properly refactored to support this properly on aarch64.
Acked-by: Will Deacon <[email protected]> Reported-by: Ard Biesheuvel <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|
|
Revision tags: v5.11-rc2, v5.11-rc1, v5.10, v5.10-rc7, v5.10-rc6, v5.10-rc5, v5.10-rc4, v5.10-rc3, v5.10-rc2, v5.10-rc1, v5.9, v5.9-rc8, v5.9-rc7, v5.9-rc6, v5.9-rc5, v5.9-rc4, v5.9-rc3, v5.9-rc2, v5.9-rc1 |
|
| #
c38d444e |
| 08-Aug-2020 |
Daniel Kolesa <[email protected]> |
drm/amd/display: add DCN support for aarch64
This adds ARM64 support into the DCN. This mainly enables support for Navi graphics cards. The dcn10 changes haven't been tested, since I don't have the
drm/amd/display: add DCN support for aarch64
This adds ARM64 support into the DCN. This mainly enables support for Navi graphics cards. The dcn10 changes haven't been tested, since I don't have the relevant hardware available, but there is no way to conditionally disable them, so I've done them anyway.
Signed-off-by: Daniel Kolesa <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|
|
Revision tags: v5.8, v5.8-rc7, v5.8-rc6, v5.8-rc5, v5.8-rc4, v5.8-rc3, v5.8-rc2, v5.8-rc1, v5.7, v5.7-rc7, v5.7-rc6, v5.7-rc5, v5.7-rc4, v5.7-rc3, v5.7-rc2, v5.7-rc1, v5.6, v5.6-rc7, v5.6-rc6, v5.6-rc5, v5.6-rc4, v5.6-rc3, v5.6-rc2, v5.6-rc1, v5.5, v5.5-rc7, v5.5-rc6, v5.5-rc5, v5.5-rc4, v5.5-rc3, v5.5-rc2, v5.5-rc1 |
|
| #
16a9dea1 |
| 07-Dec-2019 |
Timothy Pearson <[email protected]> |
amdgpu: Enable initial DCN support on POWER
DCN requires floating point support to operate. Add the appropriate x86/ppc64 guards and FPU / AltiVec / VSX context switches to DCN.
Note that the curr
amdgpu: Enable initial DCN support on POWER
DCN requires floating point support to operate. Add the appropriate x86/ppc64 guards and FPU / AltiVec / VSX context switches to DCN.
Note that the current DC20 code doesn't contain all required FPU wrappers on x86 or POWER, so this patch is insufficient to fully enable DC20 on POWER.
v2: s/X86_64/X86/g to retain previous behavior.
Signed-off-by: Timothy Pearson <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|
| #
ad808910 |
| 11-Dec-2019 |
Alex Deucher <[email protected]> |
drm/amdgpu: fix license on Kconfig and Makefiles
amdgpu is MIT licensed.
Fixes: ec8f24b7faaf3d ("treewide: Add SPDX license identifier - Makefile/Kconfig") Reviewed-by: Christian König <christian.k
drm/amdgpu: fix license on Kconfig and Makefiles
amdgpu is MIT licensed.
Fixes: ec8f24b7faaf3d ("treewide: Add SPDX license identifier - Makefile/Kconfig") Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|
|
Revision tags: v5.4, v5.4-rc8, v5.4-rc7, v5.4-rc6 |
|
| #
78c77382 |
| 29-Oct-2019 |
Anthony Koo <[email protected]> |
drm/amd/display: cleanup of function pointer tables
[Why] It is becoming increasingly hard to figure out which function is called on the different DCN versions
[How] 1. Make function pointer table
drm/amd/display: cleanup of function pointer tables
[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 <[email protected]> Reviewed-by: Aric Cyr <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|
| #
1da37801 |
| 06-Nov-2019 |
Bhawanpreet Lakha <[email protected]> |
drm/amd/display: Drop CONFIG_DRM_AMD_DC_DCN2_0 and DSC_SUPPORTED
[Why]
DCN2 and DSC are stable enough to be build by default. So drop the flags.
[How]
Remove them using the unifdef tool. The foll
drm/amd/display: Drop CONFIG_DRM_AMD_DC_DCN2_0 and DSC_SUPPORTED
[Why]
DCN2 and DSC are stable enough to be build by default. So drop the flags.
[How]
Remove them using the unifdef tool. The following commands were executed in sequence:
$ find -name '*.c' -exec unifdef -m -DCONFIG_DRM_AMD_DC_DSC_SUPPORT -DCONFIG_DRM_AMD_DC_DCN2_0 -UCONFIG_TRIM_DRM_AMD_DC_DCN2_0 '{}' ';' $ find -name '*.h' -exec unifdef -m -DCONFIG_DRM_AMD_DC_DSC_SUPPORT -DCONFIG_DRM_AMD_DC_DCN2_0 -UCONFIG_TRIM_DRM_AMD_DC_DCN2_0 '{}' ';'
In addition:
* Remove from kconfig, and replace any dependencies with DCN1_0. * Remove from any makefiles. * Fix and cleanup NV defninitions in dal_asic_id.h * Expand DCN1 ifdef to include DCN2 code in the following files: * clk_mgr/clk_mgr.c: dc_clk_mgr_create() * core/dc_resources.c: dc_create_resource_pool() * dce/dce_dmcu.c: dcn20_*lock_phy() * dce/dce_dmcu.c: dcn20_funcs * dce/dce_dmcu.c: dcn20_dmcu_create() * gpio/hw_factory.c: dal_hw_factory_init() * gpio/hw_translate.c: dal_hw_translate_init()
Signed-off-by: Leo Li <[email protected]> Signed-off-by: Bhawanpreet Lakha <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|
| #
bd95c144 |
| 11-Dec-2019 |
Alex Deucher <[email protected]> |
drm/amdgpu: fix license on Kconfig and Makefiles
amdgpu is MIT licensed.
Fixes: ec8f24b7faaf3d ("treewide: Add SPDX license identifier - Makefile/Kconfig") Reviewed-by: Christian König <christian.k
drm/amdgpu: fix license on Kconfig and Makefiles
amdgpu is MIT licensed.
Fixes: ec8f24b7faaf3d ("treewide: Add SPDX license identifier - Makefile/Kconfig") Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|
|
Revision tags: v5.4-rc5, v5.4-rc4 |
|
| #
e8a170ff |
| 16-Oct-2019 |
Nick Desaulniers <[email protected]> |
drm/amdgpu: enable -msse2 for GCC 7.1+ users
A final attempt at enabling sse2 for GCC users.
Orininally attempted in: commit 10117450735c ("drm/amd/display: add -msse2 to prevent Clang from emittin
drm/amdgpu: enable -msse2 for GCC 7.1+ users
A final attempt at enabling sse2 for GCC users.
Orininally attempted in: commit 10117450735c ("drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines")
Reverted due to "reported instability" in: commit 193392ed9f69 ("Revert "drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines"")
Re-added just for Clang in: commit 0f0727d971f6 ("drm/amd/display: readd -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines")
The original report didn't have enough information to know if the GPF was due to misalignment, but I suspect that it was. (The missing information was the disassembly of the function at the bottom of the trace, to see if the instruction pointer pointed to an instruction with 16B alignment memory operand requirements. The stack trace does show the stack was only 8B but not 16B aligned though, which makes this a strong possibility).
Now that the stack misalignment issue has been fixed for users of GCC 7.1+, reattempt adding -msse2. This matches Clang.
It will likely never be safe to enable this for pre-GCC 7.1 AND use a 16B aligned stack in these translation units.
This is only a functional change for GCC 7.1+ users, and should be boot tested.
Link: https://bugs.freedesktop.org/show_bug.cgi?id=109487 Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|
| #
00db2971 |
| 16-Oct-2019 |
Nick Desaulniers <[email protected]> |
drm/amdgpu: fix stack alignment ABI mismatch for GCC 7.1+
GCC earlier than 7.1 errors when compiling code that makes use of `double`s and sets a stack alignment outside of the range of [2^4-2^12]:
drm/amdgpu: fix stack alignment ABI mismatch for GCC 7.1+
GCC earlier than 7.1 errors when compiling code that makes use of `double`s and sets a stack alignment outside of the range of [2^4-2^12]:
$ cat foo.c double foo(double x, double y) { return x + y; } $ gcc-4.9 -mpreferred-stack-boundary=3 foo.c error: -mpreferred-stack-boundary=3 is not between 4 and 12
This is likely why the AMDGPU driver was ever compiled with a different stack alignment (and thus different ABI) than the rest of the x86 kernel. The kernel uses 8B stack alignment, while the driver was using 16B stack alignment in a few places.
Since GCC 7.1+ doesn't error, fix the ABI mismatch for users of newer versions of GCC.
There was discussion about whether to mark the driver broken or not for users of GCC earlier than 7.1, but since the driver currently is working, don't explicitly break the driver for them here.
Relying on differing stack alignment is unspecified behavior, and brittle, and may break in the future.
This patch is no functional change for GCC users earlier than 7.1. It's been compile tested on GCC 4.9 and 8.3 to check the correct flags. It should be boot tested when built with GCC 7.1+.
-mincoming-stack-boundary= or -mstackrealign may help keep this code building for pre-GCC 7.1 users.
The version check for GCC is broken into two conditionals, both because cc-ifversion is currently GCC specific, and it simplifies a subsequent patch.
Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
show more ...
|