- 19 Mar, 2019 40 commits
-
-
Eric Bernstein authored
Cross a TODO item off the list. Cleanup SIGNAL_TYPE_HDMI_FRL, it's not currently supported. Signed-off-by:
Eric Bernstein <eric.bernstein@amd.com> Reviewed-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by:
Leo Li <sunpeng.li@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Dmytro Laktyushkin authored
Get rid of DV style dml init in favour of the cleaner DC style. Signed-off-by:
Charlene Liu <Charlene.Liu@amd.com> Acked-by:
-
Evan Quan authored
Applied vdci flush workaround for Vega20 BACO. Signed-off-by:
Evan Quan <evan.quan@amd.com> Acked-by:
-
shaoyunl authored
Driver vote low to high pstate switch whenever there is an outstanding XGMI mapping request. Driver vote high to low pstate when all the outstanding XGMI mapping is terminated. Signed-off-by:
shaoyunl <shaoyun.liu@amd.com> Reviewed-by:
-
shaoyunl authored
Adjust vram base offset for XGMI mapping when update the PT entry so the address will fall into correct XGMI aperture for peer device Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Andrey Grodzovsky authored
For each device a file xgmi_device_id is created. On the first device a subdirectory named xgmi_hive_info is created, It contains a file named hive_id and symlinks named node 1-4 linking to each device in the hive. v2: Return error codes instead of '-1' and few misspellings. Signed-off-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by:
-
Nicholas Kazlauskas authored
[Why] Can happen on ASICs with 6 planes, but this isn't a bug since we haven't written outside the array. [How] Use <= instead of <. Cc: Leo Li <sunpeng.li@amd.com> Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reported-by:
Michel Dänzer <michel.daenzer@amd.com> Reviewed-by:
-
Nicholas Kazlauskas authored
[Why] New DRM versions manage locking for private objects for us, so this is no longer needed. This also prevents a WARN_ON from occurring when the private object is duplicated during the forced atomic commit that occurs from the HPD handler. The HPD handler calls drm_modeset_lock_all before the forced commit and if the private object is duplicated then the DEBUG_LOCKS_WARN_ON(ww_ctx->done_acquire) warning will be triggered since we're trying to lock something when everything should have already been locked. [How] Drop the lock and let DRM manage this. Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by:
-
Tom St Denis authored
Signed-off-by:
Tom St Denis <tom.stdenis@amd.com> Acked-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:
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:
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:
-
