linux/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c, branch v4.15

Merge tag 'drm-for-v4.15-amd-dc' of git://people.freedesktop.org/~airlied/linux

2017-11-17T22:34:42Z

Pull amdgpu DC display code for Vega from Dave Airlie: "This is the pull request for the AMD DC (display code) layer which is a requirement to program the display engines on the new Vega and Raven based GPUs. It also contains support for all amdgpu supported GPUs (CIK, VI, Polaris), which has to be enabled. It is also a kms atomic modesetting compatible driver (unlike the current in-tree display code). I've kept it separate from drm-next because it may have some things that cause you to reject it. Background story: AMD have an internal team creating a shared OS codebase for display at hw bring up time using information from their hardware teams. This process doesn't lead to the most Linux friendly/looking code but we have worked together on cleaning a lot of it up and dealing with sparse/smatch/checkpatch, and having their team internally adhere to Linux coding standards. This tree is a complete history rebased since they started opening it, we decided not to squash it down as the history may have some value. Some of the commits therefore might not reach kernel standards, and we are steadily training people in AMD to better write commit msgs. There is a major bunch of generated bandwidth calculation and verification code that comes from their hardware team. On Vega and before this is float calculations, on Raven (DCN10) this is double based. They do the required things to do FP in the kernel, and I could understand this might raise some issues. Rewriting the bandwidth would be a major undertaken in reverification, it's non-trivial to work out if a display can handle the complete set of mode information thrown at it. Future story: There is a TODO list with this, and it address most of the remaining things that would be nice to refine/remove. The DCN10 code is still under development internally and they push out a lot of patches quite regularly and are supporting this code base with their display team. I think we've reached the point where keeping it out of tree is going to motivate distributions to start carrying the code, so I'd prefer we get it in tree. I think this code is slightly better than STAGING quality but not massively so, I'd really like to see that float/double magic gone and fixed point used, but AMD don't seem to think the accuracy and revalidation of the code is worth the effort" * tag 'drm-for-v4.15-amd-dc' of git://people.freedesktop.org/~airlied/linux: (1110 commits) drm/amd/display: fix MST link training fail division by 0 drm/amd/display: Fix formatting for null pointer dereference fix drm/amd/display: Remove dangling planes on dc commit state drm/amd/display: add flip_immediate to commit update for stream drm/amd/display: Miss register MST encoder cbs drm/amd/display: Fix warnings on S3 resume drm/amd/display: use num_timing_generator instead of pipe_count drm/amd/display: use configurable FBC option in dm drm/amd/display: fix AZ clock not enabled before program AZ endpoint amdgpu/dm: Don't use DRM_ERROR in amdgpu_dm_atomic_check amd/display: Fix potential null dereference in dce_calcs.c amdgpu/dm: Remove unused forward declaration drm/amdgpu: Remove unused dc_stream from amdgpu_crtc amdgpu/dc: Fix double unlock in amdgpu_dm_commit_planes amdgpu/dc: Fix missing null checks in amdgpu_dm.c amdgpu/dc: Fix potential null dereferences in amdgpu_dm.c amdgpu/dc: fix more indentation warnings amdgpu/dc: handle allocation failures in dc_commit_planes_to_stream. amdgpu/dc: fix indentation warning from smatch. amdgpu/dc: fix non-ansi function decls. ...

drm/amdgpu: add VRAM lost query

2017-10-19T19:27:05Z

Allows userspace to figure out if VRAM was lost. Signed-off-by: Christian König Reviewed-by: Nicolai Hähnle Signed-off-by: Alex Deucher

drm/amdgpu: move the VRAM lost counter per context

2017-10-19T19:27:04Z

Instead of per device track the VRAM lost per context and return ECANCELED instead of ENODEV. Signed-off-by: Christian König Reviewed-by: Nicolai Hähnle Signed-off-by: Alex Deucher

drm/amdgpu: partial revert VRAM lost handling v2

2017-10-19T19:27:03Z

Keep blocking the CS, but revert everything else. Mapping BOs and info IOCTL are harmless and can still happen even when VRAM content ist lost. Signed-off-by: Christian König Reviewed-by: Nicolai Hähnle Signed-off-by: Alex Deucher

drm/amdgpu: add interface for editing a foreign process's priority v3

2017-10-09T20:30:24Z

The AMDGPU_SCHED_OP_PROCESS_PRIORITY_OVERRIDE ioctls are used to set the priority of a different process in the current system. When a request is dropped, the process's contexts will be restored to the priority specified at context creation time. A request can be dropped by setting the override priority to AMDGPU_CTX_PRIORITY_UNSET. An fd is used to identify the remote process. This is simpler than passing a pid number, which is vulnerable to re-use, etc. This functionality is limited to DRM_MASTER since abuse of this interface can have a negative impact on the system's performance. v2: removed unused output structure v3: change refcounted interface for a regular set operation Signed-off-by: Andres Rodriguez Acked-by: Christian König Signed-off-by: Alex Deucher

Merge branch 'drm-next-4.15-dc' of git://people.freedesktop.org/~agd5f/linux into drm-next

2017-10-09T01:21:15Z

Initial pull request for DC support. We've completed a substantial amount of the cleanup and restructuring in our TODO. There are a few additional cleanups that we are continuing to work on, but I don't think there are any showstoppers remaining. We've tried to maintain most of the history for bisect purposes. Harry made sure all the commits build. We've enabled DC for vega10 and Raven. Pre-vega10 parts can be enabled via module parameter (amdgpu.dc=1), but are not enabled by default at this point until we get further testing upstream. This code provides atomic modesetting support for DCE8 (CIK), DCE10 (Tonga, Fiji), DCE11 (CZ, ST, Polaris), DCE12 (vega10), and DCN1 (RV) including HDMI and DP audio, DP MST, and many other advanced display features. + Latest cleanups for DC from you and Harry. Note that there is some flickering on some older asics with this branch due to a regression in powerplay that has already been fixed and will be included in my next non-DC pull request next week. * 'drm-next-4.15-dc' of git://people.freedesktop.org/~agd5f/linux: (897 commits) amdgpu/dc: use kref for dc_state. amdgpu/dc: convert dc_sink to kref. amdgpu/dc: convert dc_stream_state to kref. amdgpu/dc: use kref for dc_plane_state. amdgpu/dc: convert dc_gamma to kref reference counting. amdgpu/dc: convert dc_transfer to use a kref. amdgpu/dc: kill a bunch of dead code. amdgpu/dc: set a bunch of functions to static. amdgpu/dc: kill some deadcode in dc core. amdgpu/dc: fix indentation on a couple of returns. amdgpu/dm: don't use after free. amdgpu/dc: kfree already checks for NULL. amdgpu/dc: fix a bunch of misc whitespace. amdgpu/dc: drop hw_sequencer_types.h amdgpu/dc: drop dce110_types.h amdgpu/dc: use kernel ilog2 for log_2. amdgpu/dc: don't memset after kzalloc. amdgpu/dc: inline dal grph object id functions. amdgpu/dc: inline dml_round_to_multiple amdgpu/dc: rename bios get_image symbol to something more searchable. ...

drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

2017-10-06T20:47:56Z

for being able to convert an amdgpu fence into one of the handles. Mesa will use this. Reviewed-by: Dave Airlie Signed-off-by: Marek Olšák Signed-off-by: Alex Deucher

drm/amd/dc: Add dc display driver (v2)

2017-09-26T21:01:32Z

Supported DCE versions: 8.0, 10.0, 11.0, 11.2 v2: rebase against 4.11 Signed-off-by: Harry Wentland Acked-by: Alex Deucher Signed-off-by: Alex Deucher

drm/amdgpu/sriov:fix missing error handling

2017-09-26T19:14:07Z

Signed-off-by: Monk Liu Reviewed-by: Christian König Signed-off-by: Alex Deucher

drm/amdgpu: Add PASID management

2017-09-26T17:07:02Z

Allows assigning a PASID to a VM for identifying VMs involved in page faults. The global PASID manager is also exported in the KFD interface so that AMDGPU and KFD can share the PASID space. PASIDs of different sizes can be requested. On APUs, the PASID size is deterined by the capabilities of the IOMMU. So KFD must be able to allocate PASIDs in a smaller range. Signed-off-by: Felix Kuehling Acked-by: Alex Deucher Reviewed-by: Oded Gabbay Signed-off-by: Alex Deucher