- 10 Apr, 2019 26 commits
-
-
Anthony Koo authored
[Why] If link is already enabled at a different rate (for example 5.4 Gbps) then calling VBIOS command table to switch to a new rate (for example 2.7 Gbps) will not take effect. This can lead to link training failure to occur. [How] If the requested link rate is different than the current link rate, the link must be disabled in order to re-enable at the new link rate. In today's logic it is currently only impacting eDP since DP connection types will always disable the link during display detection, when initial link verification occurs. Signed-off-by:
Anthony Koo <Anthony.Koo@amd.com> Reviewed-by:
Aric Cyr <Aric.Cyr@amd.com> Acked-by:
Leo Li <sunpeng.li@amd.com> Acked-by:
Tony Cheng <Tony.Cheng@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Anthony Koo authored
[Why] In some cases we want DC init to take in some config options [How] Init dc_config before rest of DC init Signed-off-by:
-
SivapiriyanKumarasamy authored
[Why] In HDR configurations, the cursor - in SDR - needs to have it's white level boosted. [How] Program the cursor boost in update_dchubp_dpp like the other cursor attributes. Signed-off-by:
SivapiriyanKumarasamy <sivapiriyan.kumarasamy@amd.com> Reviewed-by:
Reza Amini <Reza.Amini@amd.com> Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] We need DC's color space to match the color encoding and color space specified by userspace to correctly render YUV surfaces. [How] Convert the DRM color encoding and color range properties to the appropriate DC colorspace option and update the color space when performing surface updates. Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by:
-
Wenjing Liu authored
[why] when preferred link cap is set, we should always use preferred in all validation. we should not use preferred for some validation but use verified for others. [how] create getter function that gets verified link cap. if preferred is set, return preferred link settings instead. Signed-off-by:
Wenjing Liu <Wenjing.Liu@amd.com> Reviewed-by:
Nikola Cornij <Nikola.Cornij@amd.com> Acked-by:
-
Josip Pavic authored
[Why] Image brightness compensation for solid color full screen images is expected to be optimal for ABM 2.2 at level 3. The min reduction that is currently being enforced prevents this from being achieved. [How] Remove the min reduction for ABM 2.2 at level 3 Signed-off-by:
Josip Pavic <Josip.Pavic@amd.com> Reviewed-by:
-
Aric Cyr authored
Signed-off-by:
-
Su Sung Chung authored
[Why] Before it was returning false in the case of failure even though return type should be enum dc_status [How] Return DC_FAIL_UNSUPPORTED_1 instead Signed-off-by:
Su Sung Chung <Su.Chung@amd.com> Reviewed-by:
Eric Yang <eric.yang2@amd.com> Acked-by:
-
Nicholas Kazlauskas authored
[Why] The input color space for the plane was previously ignored even if it was set. If a limited range YUV format was given to DC then the wrong color transformation matrix was being used since DC assumed that it was full range instead. [How] Respect the given color_space format for the plane if it isn't COLOR_SPACE_UNKNOWN. Otherwise, use the implicit default since DM didn't specify. Signed-off-by:
-
Nikola Cornij authored
[why] Currently link bandwidth is calculated in two places, using the same formula. They should be unified into calling one function. [how] Replace all implementations of link bandwidth calculation with a call to a function. Signed-off-by:
-
Dmytro Laktyushkin authored
clk_mgr is called dccg in dc_state, this change fixes that Signed-off-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Reviewed-by:
Eric Bernstein <Eric.Bernstein@amd.com> Acked-by:
-
Wenjing Liu authored
[why] The existing calculation uses a wrong formula to calculate bandwidth from timing. [how] Expose the existing proper function that calculates the bandwidth, so dc_link can use it to calculate timing bandwidth correctly. Signed-off-by:
Jun Lei <Jun.Lei@amd.com> Acked-by:
-
SivapiriyanKumarasamy authored
[Why] We are incorrectly using dp_hdmi_max_pixel_clk because the units are not clear. [How] Rename to dp_hdmi_max_pixel_clk_in_khz, and change mode timing validation to use the value correctly. Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] DC provides a few visual confirmation debug options that can be dynamically changed at runtime to help debug surface programming issues but we don't have any way to access it from userspace. [How] Add the amdgpu_dm_visual_confirm debugfs entry. It accepts a string containing the DC visual confirm enum value using the debugfs attribute helpers. The debugfs_create_file_unsafe can be used instead of debugfs_create_file as per the documentation. v2: Use debugfs helpers for getting and setting the value (Christian) Cc: Leo Li <sunpeng.li@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by:
-
Nicholas Kazlauskas authored
The brace initialization used here generates warnings on some compilers. For example, on GCC 4.9: [...] In function ‘dm_determine_update_type_for_commit’: [...] error: missing braces around initializer [-Werror=missing-braces] struct dc_stream_update stream_update = { 0 }; ^ Use memset to make this more portable. v2: Specify the compiler / diagnostic in the commit message (Paul) Cc: Sun peng Li <Sunpeng.Li@amd.com> Cc: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: -
Nicholas Kazlauskas authored
The extra ; in the macro definition creates an empty statement preventing any variable declarations from occuring after any use of to_dm_plane_state(...). Signed-off-by:
-
Yintian Tao authored
Under vega10 virtualuzation, smu ip block will not be added. Therefore, we need add pp clk query and force dpm level function at amdgpu_virt_ops to support the feature. v2: add get_pp_clk existence check and use kzalloc to allocate buf v3: return -ENOMEM for allocation failure and correct the coding style Signed-off-by:
Yintian Tao <yttao@amd.com> Reviewed-by:
-
shaoyunl authored
XGMI Memory sharing will be disbaled by default for security reason after boot up, it depends on driver to enable the memory sharing Signed-off-by:
shaoyunl <shaoyun.liu@amd.com> Acked-by:
Evan Quan <evan.quan@amd.com> Signed-off-by:
-
xinhui pan authored
IP initialize ras in late_init, because of the BUGs of PSP or any other components, driver receives unexpected irqs. It is ok to add such check anyway. Signed-off-by:
xinhui pan <xinhui.pan@amd.com> Reviewed-by:
-
xinhui pan authored
handle ras enable on boot. Signed-off-by:
-
xinhui pan authored
handle ras enable on boot. Signed-off-by:
-
xinhui pan authored
handle ras enable on boot. Signed-off-by:
-
xinhui pan authored
Many parts of the whole SW stack can program the ras enablement state during the boot. Now we handle that case by adding one function which check the ras flags and choose different code path. Reviewed-by:
-
xinhui pan authored
Unless IP has implemented its own ras, use ERROR_NONE as the default type. Signed-off-by:
-
Kevin Wang authored
use smu_update_table_with_arg to replace old code logic Signed-off-by:
Kevin Wang <kevin1.wang@amd.com> Reviewed-by:
-
Kevin Wang authored
in fact, the firmware need 2 parameter: 1.table_id, 2.XferArg so change the function interface to match the firmware code Signed-off-by:
-
- 04 Apr, 2019 1 commit
-
-
Evan Quan authored
Need to check for invalid profile mode settings before determining to switch to that. Signed-off-by:
-
- 03 Apr, 2019 13 commits
-
-
Nicholas Kazlauskas authored
[Why] The actual position for the cursor on the screen is essentially: x_out = x - x_plane - x_hotspot y_out = y - y_plane - y_hotspot The register values for cursor position and cursor hotspot need to be greater than zero when programmed, but we also need to subtract off the plane position to display the cursor at the correct position. Since we don't want x or y to be less than zero, we add the plane position as a positive value to x_hotspot or y_hotspot. However, what this doesn't take into account is that the hotspot registers are limited by the maximum cursor size. On DCN10 the cursor hotspot regitsers are masked to 0xFF, so they have a maximum value of 0-255. Values greater this will wrap, causing the cursor to display in the wrong position. In practice this means that for sufficiently large plane positions, the cursor will be drawn twice on the screen, and can cause screen flashes or p-state WARNS depending on what the wrapped value is. So we need a way to remove the value from x_plane and y_plane without exceeding the maximum cursor size. [How] Subtract as much as x_plane/y_plane as possible from x and y and place the remainder in the cursor hotspot register. The value for x_hotspot and y_hotspot can still wrap around but it won't happen in a case where the cursor is actually enabled. The cursor plane needs to intersect at least one pixel of the plane's rectangle to be enabled, so the cursor position + hotspot provided by userspace must always be strictly less than the maximum cursor size for the cursor to actually be enabled. Signed-off-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by:
-
Leo Li authored
For DCN disabled builds, dc->dml is stripped out. Therefore, guard usage in dc_create_state() with CONFIG_DRM_AMD_DC_DCN1_0. It fixes the following error: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c: In function 'dc_create_state': >> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:1237:34: error: 'struct dc' has no member named 'dml' memcpy(&context->bw_ctx.dml, &dc->dml, sizeof(struct display_mode_lib)); ^~ Signed-off-by: -
Aidan Wood authored
[Why] Multiple threads were writing back to one global VBA in DC resulting in multiple threads overwriting eachother's data [How] Add an instance of DML (which contains VBA) to each context and change all calls that used dc->dml to use context->dml. Created a seperate copy constructor for linux in a case where there is no access to DC. Signed-off-by:
Aidan Wood <Aidan.Wood@amd.com> Reviewed-by:
-
Mario Kleiner authored
We want vblank counts and timestamps of flip completion as sent in pageflip completion events to be consistent with the vblank count and timestamp of the vblank of flip completion, like in non VRR mode. In VRR mode, drm_update_vblank_count() - and thereby vblank count and timestamp updates - must be delayed until after the end of front-porch of each vblank, as it is only safe to calculate vblank timestamps outside of the front-porch, when we actually know when the vblank will end or has ended. The function drm_update_vblank_count() which updates timestamps and counts gets called by drm_crtc_accurate_vblank_count() or by drm_crtc_handle_vblank(). Therefore we must make sure that pageflip events for a completed flip are only sent out after drm_crtc_accurate_vblank_count() or drm_crtc_handle_vblank() is executed, after end of front-porch for the vblank of flip completion. Two cases: a) Pageflip irq handler executes inside front-porch: In this case we must defer sending pageflip events until drm_crtc_handle_vblank() executes after end of front-porch, and thereby calculates proper vblank count and timestamp. Iow. the pflip irq handler must just arm a pageflip event to be sent out by drm_crtc_handle_vblank() later on. b) Pageflip irq handler executes after end of front-porch, e.g., after flip completion in back-porch or due to a massively delayed handler invocation into the active scanout of the new frame. In this case we can call drm_crtc_accurate_vblank_count() to safely force calculation of a proper vblank count and timestamp, and must send the pageflip completion event ourselves from the pageflip irq handler. This is the same behaviour as needed for standard fixed refresh rate mode. To decide from within pageflip handler if we are in case a) or b), we check the current scanout position against the boundary of front-porch. In non-VRR mode we just do what we did in the past. Signed-off-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by:
-
Mario Kleiner authored
In VRR mode, proper vblank/pageflip timestamps can only be computed after the display scanout position has left front-porch. Therefore delay calls to drm_crtc_handle_vblank(), and thereby calls to drm_update_vblank_count() and pageflip event delivery, to after the end of front-porch when in VRR mode. We add a new vupdate irq, which triggers at the end of the vupdate interval, ie. at the end of vblank, and calls the core vblank handler function. The new irq handler is not executed in standard non-VRR mode, so vblank handling for fixed refresh rate mode is identical to the past implementation. v2: Implement feedback by Nicholas and Paul Menzel. Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Reviewed-by:
-
Mario Kleiner authored
For throttling to work correctly, we always need a baseline vblank count last_flip_vblank that increments at start of front-porch. This is the case for drm_crtc_vblank_count() in non-VRR mode, where the vblank irq fires at start of front-porch and triggers DRM core vblank handling, but it is no longer the case in VRR mode, where core vblank handling is done later, after end of front-porch. Therefore drm_crtc_vblank_count() is no longer useful for this. We also can't use drm_crtc_accurate_vblank_count(), as that would screw up vblank timestamps in VRR mode when called in front-porch. To solve this, use the cooked hardware vblank counter returned by amdgpu_get_vblank_counter_kms() instead, as that one is cooked to always increment at start of front-porch, independent of when vblank related irq's fire. This patch allows vblank irq handling to happen anywhere within vblank of even after it, without a negative impact on flip throttling, so followup patches can shift the vblank core handling trigger point wherever they need it. Signed-off-by:
-
Mario Kleiner authored
During VRR mode we can not allow vblank irq dis-/enable transitions, as an enable after a disable can happen at an arbitrary time during the video refresh cycle, e.g., with a high likelyhood inside vblank front-porch. An enable during front-porch would cause vblank timestamp updates/calculations which are completely bogus, given the code can't know when the vblank will end as long as we are in front-porch with no page flip completed. Hold a permanent vblank reference on the crtc while in active VRR mode to prevent a vblank disable, and drop the reference again when switching back to fixed refresh rate non-VRR mode. v2: Make sure transition is also handled if vrr is disabled and stream gets disabled in the same atomic commit by moving the call to the transition function outside of plane commit. Suggested by Nicholas. v3: Trivial rebase onto previous patch. Signed-off-by: -
Mario Kleiner authored
We need the VRR active/inactive state info earlier in the commit sequence, so VRR related setup functions like amdgpu_dm_handle_vrr_transition() know the final VRR state when they need to do their hw setup work. Split update_freesync_state_on_stream() into an early part, that can run at the beginning of commit tail before the vrr transition handling, and a late part that must run after vrr transition handling inside the commit planes code for enabled crtc's. Suggested by Nicholas Kazlauskas. Signed-off-by:
-
Kent Russell authored
Vega20 stores a CUSTOM profile on the GPU, but it may not be valid. Add a bool to vega20_hwmgr to determine whether or not a valid CUSTOM profile has been set, and use that to check when a user requests switching to the CUSTOM profile without passing in any arguments. Then if the CUSTOM profile has been set already, we can switch to it without providing the parameters again Signed-off-by:
Kent Russell <kent.russell@amd.com> Reviewed-by:
-
Kent Russell authored
Don't return an error if the CUSTOM profile is selected, just apply it with the values saved to the GPU. But ensure that we zero out the copy stored in adev to ensure that a valid profile has been submitted at some point first v2: Fix comment that wasn't updated from previous patch Signed-off-by:
-
Kent Russell authored
Allow changing to the CUSTOM profile without requiring the parameters being passed in each time. Store the values in the smu7_profiling table since it's defined here anyways v2: Add check that CUSTOM was previously set Signed-off-by:
-
shaoyunl authored
Avoid unnecessary XGMI hight pstate trigger when mapping none-vram memory for peer device Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Christian König authored
We are going to need that for recoverable page faults. Signed-off-by:
-
