summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/amd/display/modules
AgeCommit message (Collapse)AuthorFilesLines
2025-10-29minmax: make generic MIN() and MAX() macros available everywhereLinus Torvalds1-0/+2
[ Upstream commit 1a251f52cfdc417c84411a056bc142cbd77baef4 ] This just standardizes the use of MIN() and MAX() macros, with the very traditional semantics. The goal is to use these for C constant expressions and for top-level / static initializers, and so be able to simplify the min()/max() macros. These macro names were used by various kernel code - they are very traditional, after all - and all such users have been fixed up, with a few different approaches: - trivial duplicated macro definitions have been removed Note that 'trivial' here means that it's obviously kernel code that already included all the major kernel headers, and thus gets the new generic MIN/MAX macros automatically. - non-trivial duplicated macro definitions are guarded with #ifndef This is the "yes, they define their own versions, but no, the include situation is not entirely obvious, and maybe they don't get the generic version automatically" case. - strange use case #1 A couple of drivers decided that the way they want to describe their versioning is with #define MAJ 1 #define MIN 2 #define DRV_VERSION __stringify(MAJ) "." __stringify(MIN) which adds zero value and I just did my Alexander the Great impersonation, and rewrote that pointless Gordian knot as #define DRV_VERSION "1.2" instead. - strange use case #2 A couple of drivers thought that it's a good idea to have a random 'MIN' or 'MAX' define for a value or index into a table, rather than the traditional macro that takes arguments. These values were re-written as C enum's instead. The new function-line macros only expand when followed by an open parenthesis, and thus don't clash with enum use. Happily, there weren't really all that many of these cases, and a lot of users already had the pattern of using '#ifndef' guarding (or in one case just using '#undef MIN') before defining their own private version that does the same thing. I left such cases alone. Cc: David Laight <David.Laight@aculab.com> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Eliav Farber <farbere@amazon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-10-17drm/amd/display: Round calculated vtotalRobin Chen1-1/+1
commit c03fca619fc687338a3b6511fdbed94096abdf79 upstream. [WHY] The calculated vtotal may has 1 line deviation. To get precisely vtotal number, round the vtotal result. Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Reviewed-by: Anthony Koo <anthony.koo@amd.com> Signed-off-by: Robin Chen <robin.chen@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-09-12drm/amd/display: Add array index check for hdcp ddc accessHersen Wu1-4/+24
[ Upstream commit 4e70c0f5251c25885c31ee84a31f99a01f7cf50e ] [Why] Coverity reports OVERRUN warning. Do not check if array index valid. [How] Check msg_id valid and valid array index. Reviewed-by: Alex Hung <alex.hung@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Hersen Wu <hersenxs.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-07-18drm/amd/display: Check index msg_id before read or writeAlex Hung1-0/+8
[ Upstream commit 59d99deb330af206a4541db0c4da8f73880fba03 ] [WHAT] msg_id is used as an array index and it cannot be a negative value, and therefore cannot be equal to MOD_HDCP_MESSAGE_ID_INVALID (-1). [HOW] Check whether msg_id is valid before reading and setting. This fixes 4 OVERRUN issues reported by Coverity. Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Acked-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-07-05drm/amd/display: revert Exit idle optimizations before HDCP executionMartin Leung2-18/+0
commit f2703a3596a279b0be6eeed4c500bdbaa8dc3ce4 upstream. why and how: causes black screen on PNP on DCN 3.5 This reverts commit f30a3bea92bd ("drm/amd/display: Exit idle optimizations before HDCP execution") Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Martin Leung <martin.leung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-05drm/amd/display: Exit idle optimizations before HDCP executionNicholas Kazlauskas2-0/+18
[ Upstream commit f30a3bea92bdab398531129d187629fb1d28f598 ] [WHY] PSP can access DCN registers during command submission and we need to ensure that DCN is not in PG before doing so. [HOW] Add a callback to DM to lock and notify DC for idle optimization exit. It can't be DC directly because of a potential race condition with the link protection thread and the rest of DM operation. Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Charlene Liu <charlene.liu@amd.com> Acked-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-13drm/amd/display: Fix nanosec stat overflowAric Cyr1-2/+2
[ Upstream commit 14d68acfd04b39f34eea7bea65dda652e6db5bf6 ] [Why] Nanosec stats can overflow on long running systems potentially causing statistic logging issues. [How] Use 64bit types for nanosec stats to ensure no overflow. Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Aric Cyr <aric.cyr@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-13drm/amd/display: Return the correct HDCP error codeRodrigo Siqueira1-0/+3
[ Upstream commit e64b3f55e458ce7e2087a0051f47edabf74545e7 ] [WHY & HOW] If the display is null when creating an HDCP session, return a proper error code. Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Acked-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-19drm/amd/display: prevent potential division by zero errorsHamza Mahfooz1-3/+6
commit 07e388aab042774f284a2ad75a70a194517cdad4 upstream. There are two places in apply_below_the_range() where it's possible for a divide by zero error to occur. So, to fix this make sure the divisor is non-zero before attempting the computation in both cases. Cc: stable@vger.kernel.org Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2637 Fixes: a463b263032f ("drm/amd/display: Fix frames_to_insert math") Fixes: ded6119e825a ("drm/amd/display: Reinstate LFC optimization") Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-28drm/amd/display: Limit user regamma to a valid valueYao Wang11-0/+4
[ Upstream commit 3601d620f22e37740cf73f8278eabf9f2aa19eb7 ] [Why] For HDR mode, we get total 512 tf_point and after switching to SDR mode we actually get 400 tf_point and the rest of points(401~512) still use dirty value from HDR mode. We should limit the rest of the points to max value. [How] Limit the value when coordinates_x.x > 1, just like what we do in translate_from_linear_space for other re-gamma build paths. Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Reviewed-by: Krunoslav Kovac <Krunoslav.Kovac@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Pavle Kotarac <Pavle.Kotarac@amd.com> Signed-off-by: Yao Wang1 <Yao.Wang1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-20drm/amd/display: Update VTEM Infopacket definitionLeo (Hanghong) Ma1-2/+3
[ Upstream commit c9fbf6435162ed5fb7201d1d4adf6585c6a8c327 ] [Why & How] The latest HDMI SPEC has updated the VTEM packet structure, so change the VTEM Infopacket defined in the driver side to align with the SPEC. Reviewed-by: Chris Park <Chris.Park@amd.com> Acked-by: Alex Hung <alex.hung@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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19drm/amd/display: Avoid HDCP over-read and corruptionKees Cook1-1/+3
[ Upstream commit 06888d571b513cbfc0b41949948def6cb81021b2 ] Instead of reading the desired 5 bytes of the actual target field, the code was reading 8. This could result in a corrupted value if the trailing 3 bytes were non-zero, so instead use an appropriately sized and zero-initialized bounce buffer, and read only 5 bytes before casting to u64. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19drm/amd/display: fix HDCP reset sequence on reinitializeBrandon Syu1-1/+0
[ Upstream commit 99c248c41c2199bd34232ce8e729d18c4b343b64 ] [why] When setup is called after hdcp has already setup, it would cause to disable HDCP flow won’t execute. [how] Don't clean up hdcp content to be 0. Signed-off-by: Brandon Syu <Brandon.Syu@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Acked-by: Wayne Lin <waynelin@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-19drm/amd/display: add handling for hdcp2 rx id list validationDingchen (David) Zhang1-0/+2
[ Upstream commit 4ccf9446b2a3615615045346c97f8a1e2a16568a ] [why] the current implementation of hdcp2 rx id list validation does not have handler/checker for invalid message status, e.g. HMAC, the V parameter calculated from PSP not matching the V prime from Rx. [how] return a generic FAILURE for any message status not SUCCESS or REVOKED. Signed-off-by: Dingchen (David) Zhang <dingchen.zhang@amd.com> Reviewed-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30drm/amdgpu: fix build_coefficients() argumentArnd Bergmann1-1/+1
[ Upstream commit dbb60031dd0c2b85f10ce4c12ae604c28d3aaca4 ] gcc -Wextra warns about a function taking an enum argument being called with a bool: drivers/gpu/drm/amd/amdgpu/../display/modules/color/color_gamma.c: In function 'apply_degamma_for_user_regamma': drivers/gpu/drm/amd/amdgpu/../display/modules/color/color_gamma.c:1617:29: warning: implicit conversion from 'enum <anonymous>' to 'enum dc_transfer_func_predefined' [-Wenum-conversion] 1617 | build_coefficients(&coeff, true); It appears that a patch was added using the old calling conventions after the type was changed, and the value should actually be 0 (TRANSFER_FUNCTION_SRGB) here instead of 1 (true). Fixes: 55a01d4023ce ("drm/amd/display: Add user_regamma to color module") Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-18drm/amd/display: Don't log hdcp module warnings in dmesgBhawanpreet Lakha1-1/+1
[Why] DTM topology updates happens by default now. This results in DTM warnings when hdcp is not even being enabled. This spams the dmesg and doesn't effect normal display functionality so it is better to log it using DRM_DEBUG_KMS() [How] Change the DRM_WARN() to DRM_DEBUG_KMS() Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-09-16drm/amd/display: Don't use DRM_ERROR() for DTM add topologyBhawanpreet Lakha1-1/+1
[Why] Previously we were only calling add_topology when hdcp was being enabled. Now we call add_topology by default so the ERROR messages are printed if the firmware is not loaded. This error message is not relevant for normal display functionality so no need to print a ERROR message. [How] Change DRM_ERROR to DRM_INFO Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-09-16drm/amd/display: Fix CP_IRQ clear bit and logicHarmanprit Tatla2-11/+8
[Why] Currently clearing the wrong bit for CP_IRQ, and logic on when to clear needs to be fixed. [How] Corrected bit to clear and improved logic for decision to clear. Signed-off-by: Harmanprit Tatla <harmanprit.tatla@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-09-16drm/amd/display: Add CP_IRQ clear capabilityHarmanprit Tatla3-0/+29
[Why] Currently we do not clear the CP_IRQ bit upon receiving it. [How] Added a function to clear CP_IRQ bit. Signed-off-by: Harmanprit Tatla <harmanprit.tatla@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-08-26drm/amd/display: Send H14b-VSIF specified in HDMIWayne Lin2-15/+3
[Why] Current function excludes the logic to generate H14b-VSIF. Now it constructs HF-VSIF only and causes HDMI compliace test fail. [How] According to HDMI spec, source devices shall utilize the H14b-VSIF whenever the signaling capabilities of the H14b-VSIF allow this. Here keep the logic for HF-VSIF and add H14b-VSIF construction part. Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Acked-by: Eryk Brol <eryk.brol@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-08-17drm/amd/display: Change ABM config init interfaceYongqiang Sun2-5/+18
[Why & How] change abm config init interface to support multiple ABMs. Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by: Chris Park <Chris.Park@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-08-11drm/amd/display: Fix LFC multiplier changing erraticallyAnthony Koo1-7/+29
[Why] 1. There is a calculation that is using frame_time_in_us instead of last_render_time_in_us to calculate whether choosing an LFC multiplier would cause the inserted frame duration to be outside of range. 2. We do not handle unsigned integer subtraction correctly and it underflows to a really large value, which causes some logic errors. [How] 1. Fix logic to calculate 'within range' using last_render_time_in_us 2. Split out delta_from_mid_point_delta_in_us calculation to ensure we don't underflow and wrap around Signed-off-by: Anthony Koo <Anthony.Koo@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-07-30drm/amd/display: Allow asic specific FSFT timing optimizationReza Amini1-1/+4
[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-21drm/amd/display: Implement AMD VSIF V3Reza Amini1-0/+41
[Why] To support V3 [How] Generate new VSIF for V3 Signed-off-by: Reza Amini <Reza.Amini@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-07-08drm/amd/display: Send VSIF on unsupported modes on DALJaehyun Chung1-1/+1
[Why] Current DAL behaviour is to not send VSIF if mode does not support VRR (ie. FS range is < 10Hz). However, we should still set FS Native Color Active bit in some unsupported mode cases. [How] Remove check for if VRR is supported before building infopacket. Signed-off-by: Jaehyun Chung <jaehyun.chung@amd.com> Reviewed-by: Anthony Koo <Anthony.Koo@amd.com> Acked-by: Eryk Brol <eryk.brol@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-02drm/amd/display: Fix incorrect rounding for 10Hz refresh rangeJaehyun Chung2-32/+10
[Why] In cases where refresh range is slightly below 10, FreeSync is not active or supported. Need to round values before checking refresh range in order to have FreeSync supported in these cases. [How] Remove redundant values and round values before checking valid refresh range. Signed-off-by: Jaehyun Chung <jaehyun.chung@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-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-01drm/amd/display: fix compilation error on allmodconfigQingqing Zhuo1-5/+1
when compiled with allmodconfig option, there are error messages as below: ERROR: modpost: "mod_color_is_table_init" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "mod_color_get_table" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "mod_color_set_table_init_state" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! To fix the issue, this commits removes CONFIG_DRM_AMD_DC_DCN guard in color/makefile. Signed-off-by: Qingqing Zhuo <qingqing.zhuo@amd.com> CC: Lewis Huang <Lewis.Huang@amd.com> CC: Aric Cyr <Aric.Cyr@amd.com> CC: Alexander Deucher <Alexander.Deucher@amd.com> CC: Harry Wentland <hwentlan@amd.com> CC: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> CC: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> CC: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-01drm/amd: add missing fill of the array`s first elementBernard Zhao1-0/+1
In function fill_iram_v_2, the ram_table->bright_neg_gain`s first element [0][0] seems to be missing. This change is just to make the code a bit readable. Signed-off-by: Bernard Zhao <bernard@vivo.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-01drm/amd/display: change global buffer to local bufferLewis Huang5-57/+175
[Why] Multi-adapter calculate regamma table at the same time. Two thread used the same global variable cause race condition. [How] Change global buffer to local buffer Signed-off-by: Lewis Huang <Lewis.Huang@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-07-01drm/amd/display: Use kfree() to free rgb_user in calculate_user_regamma_ramp()Denis Efremov1-1/+1
Use kfree() instead of kvfree() to free rgb_user in calculate_user_regamma_ramp() because the memory is allocated with kcalloc(). Signed-off-by: Denis Efremov <efremov@linux.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-01drm/amd/display: Use kvfree() to free coeff in build_regamma()Denis Efremov1-1/+1
Use kvfree() instead of kfree() to free coeff in build_regamma() because the memory is allocated with kvzalloc(). Fixes: e752058b8671 ("drm/amd/display: Optimize gamma calculations") Cc: stable@vger.kernel.org Signed-off-by: Denis Efremov <efremov@linux.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-05-28drm/amd/display: combine public interfaces into single headerAnthony Koo1-1/+1
[Why] We want to better encapsulate all driver-fw dependencies into a single file. [How] Combine all the headers under inc folder into a single header Signed-off-by: Anthony Koo <Anthony.Koo@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-05-28drm/amd/display: Fix ABM memory alignment issueWyatt Wood1-3/+42
[Why] Due to packing of abm_config_table, memory addresses aren't aligned to 32 bit boundary dmcub prefers. Therefore when using pointers to this structure, it's possible that dmcub will automatically align the data read from that address, yielding incorrect values. [How] Instead of packing 1 byte boundary, explicitly pack values to 4 byte boundary. Since there is a dependency on the existing iram table structure on driver side, we must copy to a second structure, which is aligned correctly, before passing to fw. Signed-off-by: Wyatt Wood <wyatt.wood@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: Add bit swap helper based on endiannessRodrigo Siqueira1-24/+26
Christian Koenig pointed out a code duplication related to bit swap in case of big-endian manipulation. This commit adds a helper for handling this verification and reduces the requirement of replicate some part of the code. Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Reviewed-by: Wyatt Wood <Wyatt.Wood@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-05-28drm/amd/display: Handle persistence in DMJaehyun Chung1-1/+7
[Why] Remove dm_write_persistent_data and dm_read_persistent_data as persistence should be handled in DM. [How] Remove functions. Move read/write calls into DM layer while maintaining logic. Signed-off-by: Jaehyun Chung <jaehyun.chung@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: correct rn NUM_VMIDDmytro Laktyushkin1-2/+5
Save the correct num vmid during resource creation and fix RN gpuvm level from 1 to 16 vmid entries. Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Reviewed-by: Eric Bernstein <Eric.Bernstein@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 location of dmub_srv.h fileAnthony Koo1-1/+0
[Why] Make a separation of what belongs in the differen dmub headers dmub_srv.h is for exposing dmub srv interface to rest of driver. other headers inside dmub/inc exposes cmds and definitions that are owned by the firmware [How] keep firmware owned definitions in dmub/inc move stuff that is purely driver interface headers to dmub/ since those are interface calls that are defined for rest of driver to use Signed-off-by: Anthony Koo <Anthony.Koo@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-05-05drm/amd/display: remove unused module/statsAurabindo Pillai1-448/+0
Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-05-05drm/amd/display: add addition dc type to translate to dmub fw typeAnthony Koo1-1/+1
[Why] For a type like PSR version, it makes sense for most of the code to include a dc type, instead of having this a fw type define since this is a capability and type exposed by dc. Especially if it doesn't even need to communicate with the fw. The code that is packing the firmware command message should be the one who needs to translate the psr version into a command that the firmware understands. [How] Add a dc_psr_version enum. Signed-off-by: Anthony Koo <Anthony.Koo@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-04-28drm/amd/display: Internal refactoring to abstract color capsKrunoslav Kovac2-7/+28
[Why&How] modules/color calculates various colour operations which are translated to abstracted HW. DCE 5-12 had almost no important changes, but starting with DCN1, every new generation comes with fairly major differences in color pipeline. We would hack it with some DCN checks, but a better approach is to abstract color pipe capabilities so modules/DM can decide mapping to HW block based on logical capabilities, Signed-off-by: Krunoslav Kovac <Krunoslav.Kovac@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-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-23drm/amd/display: Convert memory from cpu to fw endianness correctlyWyatt Wood1-27/+31
[Why] Current code does not guarantee the correct endianness of memory being copied to fw, specifically in the case where cpu isn't little endian. [How] Windows and Diags are always little endian, so we define a macro that does nothing. Linux already defines this macro and will do the correct endianness conversion. Signed-off-by: Wyatt Wood <wyatt.wood@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Acked-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-04-23drm/amd/display: Change infopacket type programmingHaiyi Zhou3-10/+99
[Why] Certain displays may experience blanking if infopacket max range does not equal nominal refresh rate. [How] Add additional infopacket versions to program range to full or forced range in freesync states. This does not change the vrr logic. Signed-off-by: Haiyi Zhou <haiyi.zhou@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-04-23drm/amd/display: Check ramp != NULL before applying lut1d for degammaNicholas Kazlauskas1-1/+1
[Why] A NULL ramp is a valid configuration for passing into mod_color_calculate_degamma_params but we'll hit a NULL pointer if we do so. We need this in order to get the right transfer function to do degamma on NV12 formats where we aren't supplied with a custom user degamma. [How] Add the NULL check. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Zhan Liu <Zhan.Liu@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-04-23drm/amd/display: Unify psr feature flagsWyatt Wood1-1/+2
[Why] As it stands, psr has feature flags in dm, stream, and link. Most are not defined well enough, and different dm layers have different uses for these same flags. [How] We define a new structure called psr_settings in dc_link that will hold the following psr feature flags: psr_feature_enable - psr is supported psr_allow_active - psr is currently active psr_version - internal psr version supported psr_frame_capture_indication_req psr_sdp_transmit_line_num_deadline The last two flags were moved out of the power module for the purposes of consolidating psr flags. Their use is already well-defined. Psr caps reported by sink will also be stored in dc_link, in dpcd_caps.psr_caps. Signed-off-by: Wyatt Wood <wyatt.wood@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-04-23drm/amd/display: Remove byte swapping for dmcub abm config tableWyatt Wood1-38/+36
[Why] Since x86 and dmcub are both little endian, byte swapping isn't necessary. Dmcu requires byte swapping as it is big endian. [How] Add flag to function definitions to determine if byte swapping is necessary. Signed-off-by: Wyatt Wood <wyatt.wood@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-04-09drm/amd/display: Fix ABM config copy for dmcubWyatt Wood2-10/+23
Decouple dmcub config copy from dmcu iram copy. Signed-off-by: Wyatt Wood <wyatt.wood@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-04-09drm/amd/display: fix typoJoseph Gravenor3-8/+8
[why] MOD_HDCP_STATUS_HDCP1_ENABLE_ENCRYPTION and MOD_HDCP_STATUS_HDCP2_ENABLE_ENCRYPTION were supposed to be MOD_HDCP_STATUS_HDCP1_ENABLE_ENCRYPTION_FAILURE and MOD_HDCP_STATUS_HDCP2_ENABLE_ENCRYPTION_FAILURE. Because of this it always seems like mod_hdcp_hdcp1_enable_encryption and mod_hdcp_hdcp2_enable_encryption are always passing [how] rename the elements to what they were supposed to be called Signed-off-by: Joseph Gravenor <joseph.gravenor@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-04-09drm/amd/display: Remove hdcp display state with mst fixIsabel Zhang6-47/+26
[Why] Due to previous code changes, displays transition from active to active and added state immediately, making it redundant to have both display states. Previous change to fix this caused HDCP to get into a bad state when monitor is connected to MST hub, this change fixes that issue. [How] Change code behavior so when a device is added successfully the state remains as active and when addition is unsuccessful change state to inactive. This removes need for added and active state. Signed-off-by: Isabel Zhang <isabel.zhang@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-04-09drm/amd/display: Implement abm config table copy to dmcubWyatt Wood1-2/+2
[Why] Driver must pass abm config table to dmub fw. This provides various parameters for abm functionality. [How] There is too much data to be passed in an inbox message, so we must pass this data using an indirect buffer. Copy the table to cw7 via x86, driver copies to fw_state structure. Signed-off-by: Wyatt Wood <wyatt.wood@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by: Tony Cheng <Tony.Cheng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-04-04drm/amd/display: Guard calls to hdcp_ta and dtm_taBhawanpreet Lakha1-167/+253
[Why] The buffer used when calling psp is a shared buffer. If we have multiple calls at the same time we can overwrite the buffer. [How] Add mutex to guard the shared buffer. Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.39.0) at 2026-01-25 20:31:50 +0300