- 19 Mar, 2019 40 commits
-
-
Tom St Denis authored
Signed-off-by:
Tom St Denis <tom.stdenis@amd.com> Acked-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Christian König authored
Only GMC9 supports true huge pages, but we can still free invalid mappings on GMC8. Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Acked-by:
Huang Rui <ray.huang@amd.com> Signed-off-by:
-
Christian König authored
Not needed any more since we now free PDs/PTs on demand. Signed-off-by:
-
Christian König authored
When something is unmapped we now free the affected PDs/PTs again. Signed-off-by:
-
Christian König authored
Let's start to allocate VM PDs/PTs on demand instead of pre-allocating them during mapping. Signed-off-by:
-
Christian König authored
Instead of providing it from outside figure out the ats status in the function itself from the data structures. v2: simplify finding the right level v3: partially revert changes from v2, more cleanup and split code into more functions. Signed-off-by: -
Christian König authored
This way we only deal with the real BO in here. v2: use a do { ... } while loop instead v3: fix NULL pointer in v2 Signed-off-by: -
Likun Gao authored
The operation of mutex_unlock smu->mutex should be done when forced level is larger than NUM_LINK_LEVELS in the function of force_clk_levels. Reported-by:
Julia Lawall <julia.lawall@lip6.fr> Signed-off-by:
Likun Gao <Likun.Gao@amd.com> Reviewed-by:
-
kbuild test robot authored
Simplify the code a bit by using kmemdup instead of kzalloc and memcpy. Generated by: scripts/coccinelle/api/memdup.cocci CC: Likun Gao <Likun.Gao@amd.com> Reviewed-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
Colin Ian King authored
An earlier commit replaced ttm_bo_wait with amdgpu_bo_sync_wait and removed the error return assignment to variable ret. Fix this by adding the assignment back. Also break line to clean up checkpatch overly long line warning. Detected by CoverityScan, CID#1477327 ("Logically dead code") Fixes: c60cd590 ("drm/amdgpu: Replace ttm_bo_wait with amdgpu_bo_sync_wait") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Christian König authored
Same patch we alredy did for Vega10. Just re-route page faults to a separate ring to avoid drowning in interrupts. Signed-off-by:
-
Christian König authored
Page faults can easily overwhelm the interrupt handler. So to make sure that we never lose valuable interrupts on the primary ring we re-route page faults to IH ring 1. Signed-off-by:
-
Murton Liu authored
Check if we get any values equal to 0, and set to 1 if so. Signed-off-by:
Murton Liu <murton.liu@amd.com> Reviewed-by:
Aric Cyr <Aric.Cyr@amd.com> Acked-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Acked-by:
Sivapiriyan Kumarasamy <Sivapiriyan.Kumarasamy@amd.com> Signed-off-by:
-
Tao Zhou authored
Adding thick tile mode for Oland to prevent UMD from getting mode value 0 Signed-off-by:
Tao Zhou <tao.zhou1@amd.com> Tested-by:
Hui.Deng <hui.deng@amd.com> Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warning: drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c: In function ‘gfx_v8_0_tiling_mode_table_init’: ./include/linux/device.h:1487:2: warning: this statement may fall through [-Wimplicit-fallthrough=] _dev_warn(dev, dev_fmt(fmt), ##__VA_ARGS__) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:3236:3: note: in expansion of macro ‘dev_warn’ dev_warn(adev->dev, ^~~~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:3240:2: note: here case CHIP_CARRIZO: ^~~~ Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Jakub Wilk authored
The symbol for binary prefix kibi is "Ki", with uppercase K. (In contrast, the symbol for decimal kilo is lowercase "k".) Signed-off-by:
Jakub Wilk <jwilk@jwilk.net> Signed-off-by:
-
Yang Wei authored
Delete superfluous semicolons. Signed-off-by:
Yang Wei <yang.wei9@zte.com.cn> Signed-off-by:
-
Huang Rui authored
Raven series doesn't support sw smu so far, so we have to add checking to confirm it return false while the asic is raven. Signed-off-by:
-
Nicholas Kazlauskas authored
To help xf86-video-amdgpu and mesa know DC supports updating the tiling attributes for a framebuffer per-flip. Cc: Michel Dänzer <michel@daenzer.net> Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by:
Marek Olšák <marek.olsak@amd.com> Signed-off-by:
-
Charlene Liu authored
res_pool->pp_smu may be NULL. Check before use Signed-off-by:
Charlene Liu <charlene.liu@amd.com> Reviewed-by:
Krunoslav Kovac <Krunoslav.Kovac@amd.com> Acked-by:
-
Aric Cyr authored
Signed-off-by:
-
Anthony Koo authored
[Why] AUX transaction returns success, but data has invalid lane count and rate which when passed to VBIOS command table causes it to soft hang [How] Do some sanity checking and fail if the DPCD caps are invalid. Signed-off-by:
Anthony Koo <Anthony.Koo@amd.com> Reviewed-by:
Tony Cheng <Tony.Cheng@amd.com> Acked-by:
-
Nicholas Kazlauskas authored
[Why] Tiling and DCC attributes can change when swapping framebuffers but these will only ever get updated on full commits where state->allow_modeset is true. But for the page-flip IOCTL state->allow_modeset = false so these aren't updated and DCC changes aren't being programmed. [How] Split out updating the tiling and DCC attributes into its own function that's called when creating the plane for the first time but also called when switching framebuffers before commit stream updates. These functions also don't modify the plane state directly since the plane state being used as reference is often the current one being used by the hardware. DC needs to be able to compare plane_state to the stream update structures to determine if the hardware programming should happen. If it's modified in place then nothing will be programmed and we can run into concurrency issues. Signed-off-by:
Harry Wentland <Harry.Wentland@amd.com> Acked-by:
-
David Francis authored
[Why] The dc_gamma_type CUSTOM_GAMMA is used to represent degamma mappings passed in by drm. This type of gamma must be interpolated into a transfer function by apply_1d_lut. The line in mod_color_calculate_degamma_params that handled this case was erroneously removed. [How] For CUSTOM_GAMMA degamma, calculate the lut as before. Signed-off-by:
David Francis <David.Francis@amd.com> Reviewed-by:
-
Charlene Liu authored
This reverts commit 6bff1cc7780cca2fd2a775aa7b18b789e2a1b608. [Description] Revert since this will be checked at CP side. Signed-off-by:
-
Martin Leung authored
[Why] used to be unable to run 4:2:0 if using a dongle because 4k60 bandwidth exceeded dongle caps [How] half pixel clock during comparison to dongle cap. *Could get stuck on black screen on monitor that don't support 420 but will be selecting 420 as preferred mode* Signed-off-by:
Martin Leung <martin.leung@amd.com> Reviewed-by:
Wenjing Liu <Wenjing.Liu@amd.com> Acked-by:
Aidan Wood <Aidan.Wood@amd.com> Acked-by:
-
Anthony Koo authored
[Why] UEFI boot usually uses a boot profile that uses higher clocks and watermark settings. UEFI boot surface is less optimal, for example it uses linear surface [How] Before we finish our seamless boot sequence, keep the clock and watermark settings from boot. Update to optimal settings only after first flip away from UEFI frame buffer. Signed-off-by:
-
David Francis authored
[Why] commit_planes is indented quite far [How] Move the pageflip code from an if statement to after a continue Signed-off-by:
-
David Francis authored
[Why] IGT expects that pageflips can be triggered with the same framebuffer before and after the commit [How] Expand the definition of pageflip to include any change with an old framebuffer and a new framebuffer, even if they're the same Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] Raven has support for combining pipes for DRM_PLANE_TYPE_OVERLAY use but no overlays are exposed to userspace. [How] Expose overlay planes based on DC plane caps. If all the pipes are in use then the atomic commits can fail, but this is expected behavior for userspace. Only support RGB on overlays for now. Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] Primary and underlay planes were previously exposed to DRM by using max_planes and max_slave_planes. The value for max_planes was always pipe_count + has_underlay. If there was an underlay pipe, then max_slave_planes = 1. Raven has pipe_count = 4, max_planes = 4, and max_slave_planes = 1. So during plane initialziation it was actually "creating" 1 overlay plane and 3 primary planes... or it would be, had its plane_type array not been dm_plane_type_default, which will only create DRM_PLANE_TYPE_PRIMARY planes. We can expose primary planes as supporting more than one CRTC at a time to more closely resemble plane behavior on DCN but userspace doesn't really expect planes to be used in this manner and will either ignore the planes or crash. Planes with index greater than max_streams are marked as supporting all CRTCs. No ASIC currently has primary plane count greater than the stream count but we shouldn't expose more than necessary. [How] Drop support for underlay planes. They aren't well tested and don't fully work right at the moment. Only create one primary plane per CRTC so we're not creating overlays. Initialize plane types directly instead of referencing a misleading array of plane types. Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] The current dc_caps doesn't provide the information needed to determine the count and type of each plane to be exposed to userspace. There are three types of DRM planes that are exposed to userspace: 1. Primary planes (can be used for modesetting) 2. Overlay planes (can be blended below or above a primary plane) 3. Cursor planes (blended topmost) We need to know the number and type of each in amdgpu_dm to expose to userspace. Hardware supports blending planes below, above or both ways depending on the ASIC. Alpha support is also ASIC dependent. Some hardware has dedicated pipes for overlays and other hardware combines the pipes. All of this should be exposed in a way that DM can query and use. [How] Introduce the dc_plane_cap structure that describes the capabilities for the hw planes. It describes: - the type of the plane - whether the plane can blend with planes below it - whether the plane can blend with planes above it - whether the plane supports per pixel alpha blending - supported formats on the plane (partial list for now) Pre DCN ASICs don't have their full capabilities described for now. They can be updated as needed in the future. Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] The kms_plane@plane-position-covered-pipe-*-planes subtests can produce a sequence of atomic commits such that neither active_changed nor mode_changed but connectors_changed. When this happens we remove the old stream from the context and add a new stream but the new stream doesn't have mode_changed=true set. This incorrect programming sequence causes CRC mismatches to occur in the test. The stream->mode_changed value should be set whenever a new stream is created. [How] A new stream is created whenever drm_atomic_crtc_needs_modeset is true. We previously covered the active_changed and mode_changed conditions for the CRTC but connectors_changed is also checked within drm_atomic_crtc_needs_modeset. So just use drm_atomic_crtc_needs_modeset directly to determine the mode_changed flag. Signed-off-by:
Sun peng Li <Sunpeng.Li@amd.com> Acked-by:
-
Thomas Lim authored
[Why] The new aux implementation was not up to spec. This caused us to fail DP compliance as well as introduced serious delays during system resume. [How] Make dce_aux_transfer_raw return the operation result Make dce_aux_transfer_with_retries delay with udelay instead of msleep, and only on invalid reply. Also fail on the second invalid reply, third timeout, or first of any other error Convert return values to drm error codes in amdgpu_dm As the two aux transfer functions are now noticeably different, change the names to better reflect their functionality and document. There was one last call to dc_link_aux_transfer that should have retries, fix that Signed-off-by:
Thomas Lim <Thomas.Lim@amd.com> Reviewed-by:
Eric Yang <eric.yang2@amd.com> Signed-off-by:
-
Tyler DiBattista authored
[Why] Implemented for future use Signed-off-by:
Tyler DiBattista <tyler.dibattista@amd.com> Reviewed-by:
Eric Bernstein <Eric.Bernstein@amd.com> Acked-by:
-
Jun Lei authored
In some cases we might need to do a full update. Add a commit_hints struct for future use Signed-off-by:
Jun Lei <Jun.Lei@amd.com> Reviewed-by:
-
Martin Tsai authored
[Why] With special monitor combination on MST, the UP_REQ could come after clear payload table. It makes the pending DOWN_REP fail to be handled after link training and the new DOWN_REQ will be queued until time out . [How] To move the current polling pending DOWN_REP procedure to after clear payload table to make sure the pending DOWN_REP can be done before enabling the link. Signed-off-by:
Martin Tsai <martin.tsai@amd.com> Reviewed-by:
-
Kent Russell authored
Add 6 files that return (in bytes): The total amount of VRAM/visible VRAM/GTT and the current total used VRAM/visible VRAM/GTT v2: Split used and total into separate files Reviewed-by:
Kent Russell <kent.russell@amd.com> Signed-off-by:
-
Likun Gao authored
Add condition to judge whether overdrive is enabled and correct power limit value for overdrive used by power limit interface. Signed-off-by:
Kevin Wang <kevin1.wang@amd.com> Reviewed-by:
-
Likun Gao authored
Move pp_feature from the struct of amd_powerplay to amdgpu_device. Add pp_feature limit for overdrive interface. v2: put pp_feature into struct amdgpu_pm. v3: merge feature_mask with pp_feature. Signed-off-by:
-
