- Apr 11, 2019
-
-
Aric Cyr authored
Signed-off-by:
Aric Cyr <aric.cyr@amd.com> Reviewed-by:
Leo Li <sunpeng.li@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
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:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-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:
Nikola Cornij <nikola.cornij@amd.com> Reviewed-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:
Wenjing Liu <Wenjing.Liu@amd.com> Reviewed-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:
SivapiriyanKumarasamy <sivapiriyan.kumarasamy@amd.com> Reviewed-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:
-
- Apr 04, 2019
-
-
Evan Quan authored
Need to check for invalid profile mode settings before determining to switch to that. Signed-off-by:
-
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:
-
- Apr 03, 2019
-
-
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:
-
Christian König authored
This way we get retry faults for missing PDs. Signed-off-by:
-
Christian König authored
Otherwise we don't correctly use translate further. Signed-off-by:
-
shaoyunl authored
According to HW engineer, they prefer the TMR address be "naturally aligned", e.g. the start address must be an integer divide of TME size. Signed-off-by:
-
Emily Deng authored
Fix the issue about TDR-2 will have "fallback timer expired on ring sdma1". It is because the wrong number of irq types setting. Signed-off-by:
Emily Deng <Emily.Deng@amd.com> Reviewed-by:
-
git://linux-arm.org/linux-ldDave Airlie authored
This pull requests adds initial Mali D71 support into the Arm "komeda" DRM driver. The code has been reviewed at the end of last year, I just been too slow with pushing it into mainline. Since it started baking in linux-next we had a kbuild-bot issue raised and one from Joe Perches on the MAINTAINERS entry, for which I'm including fixes here. Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Liviu Dudau <Liviu.Dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190401192833.GW21747@e110455-lin.cambridge.arm.com
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
amdgpu: - Switch to HMM for userptr (reverted until HMM fixes land) - New experimental SMU 11 replacement for powerplay for vega20 (not enabled by default) - Initial RAS support for vega20 - BACO support for vega12 - BACO fixes for vega20 - Rework IH handling for page fault and retry interrupts - Cleanly split CPU and GPU paths for GPUVM updates - Powerplay fixes - XGMI fixes - Rework how DC interacts with atomic for planes - Clean up and simplify DC/Powerplay interfaces - Misc cleanups and bug fixes amdkfd: - Switch to HMM for userptr (reverted until HMM fixes land) - Add initial RAS support - MQD fixes ttm: - Unify DRM_FILE_PAGE_OFFSET handling - Account for kernel allocations in kernel zone only - Misc cleanups Signed-off-by:
-
