summaryrefslogtreecommitdiffstats
path: root/include/uapi/drm/msm_drm.h
Commit message (Collapse)AuthorAgeFilesLines
* drm/msm: Add MSM_SUBMIT_FENCE_SN_INRob Clark2022-03-041-1/+3
| | | | | | | | | | | | | | | Add a way for userspace to specify the sequence number fence used to track completion of the submit. As the seqno fence is simply an incrementing counter which is local to the submitqueue, it is easy for userspace to know the next value. This is useful for native userspace drivers in a vm guest, as the guest to host roundtrip can have high latency. Assigning the fence seqno in the guest userspace allows the guest to continue without waiting for response from the host. Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20220224222321.60653-1-robdclark@gmail.com
* drm/msm: Add SYSPROF param (v2)Rob Clark2022-03-041-0/+1
| | | | | | | | | | | | | | | | Add a SYSPROF param for system profiling tools like Mesa's pps-producer (perfetto) to control behavior related to system-wide performance counter collection. In particular, for profiling, one wants to ensure that GPU context switches do not effect perfcounter state, and might want to suppress suspend (which would cause counters to lose state). v2: Swap the order in msm_file_private_set_sysprof() [sboyd] and initialize the sysprof_active refcount to one (because the under/ overflow checking in refcount_t doesn't expect a 0->1 transition) meaning that values greater than 1 means sysprof is active. Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20220304005317.776110-4-robdclark@gmail.com
* drm/msm: Add SET_PARAM ioctlRob Clark2022-03-041-12/+15
| | | | | | | | | It was always expected to have a use for this some day, so we left a placeholder. Now we do. (And I expect another use in the not too distant future when we start allowing userspace to allocate GPU iova.) Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20220304005317.776110-3-robdclark@gmail.com
* drm/msm: Utilize gpu scheduler prioritiesRob Clark2021-07-281-1/+13
| | | | | | | | | | | | | | The drm/scheduler provides additional prioritization on top of that provided by however many number of ringbuffers (each with their own priority level) is supported on a given generation. Expose the additional levels of priority to userspace and map the userspace priority back to ring (first level of priority) and schedular priority (additional priority levels within the ring). Signed-off-by: Rob Clark <robdclark@chromium.org> Acked-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20210728010632.2633470-13-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
* drm/msm: deprecate MSM_BO_UNCACHED (map as writecombine instead)Jonathan Marek2021-06-231-1/+1
| | | | | | | | | | | | There shouldn't be any reason to ever use uncached over writecombine, so just use writecombine for MSM_BO_UNCACHED. Note: userspace never used MSM_BO_UNCACHED anyway Signed-off-by: Jonathan Marek <jonathan@marek.ca> Acked-by: Jordan Crouse <jordan@cosmicpenguin.net> Link: https://lore.kernel.org/r/20210423190833.25319-6-jonathan@marek.ca Signed-off-by: Rob Clark <robdclark@chromium.org>
* drm/msm: add MSM_BO_CACHED_COHERENTJonathan Marek2021-06-231-3/+2
| | | | | | | | | Add a new cache mode for creating coherent host-cached BOs. Signed-off-by: Jonathan Marek <jonathan@marek.ca> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Link: https://lore.kernel.org/r/20210423190833.25319-5-jonathan@marek.ca Signed-off-by: Rob Clark <robdclark@chromium.org>
* drm/msm: Add param for userspace to query suspend countRob Clark2021-04-071-0/+1
| | | | | | | | | | | | | Performance counts, and ALWAYS_ON counters used for capturing GPU timestamps, lose their state across suspend/resume cycles. Userspace tooling for performance monitoring needs to be aware of this. For example, after a suspend userspace needs to recalibrate it's offset between CPU and GPU time. Signed-off-by: Rob Clark <robdclark@chromium.org> Acked-by: Jordan Crouse <jordan@cosmicpenguin.net> Link: https://lore.kernel.org/r/20210325012358.1759770-3-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
* drm: msm_drm.h: delete duplicated words in commentsRandy Dunlap2020-07-151-2/+2
| | | | | | | | | | | Drop the doubled word "to" in comments. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200715052349.23319-6-rdunlap@infradead.org
* drm/msm: Add syncobj support.Bas Nieuwenhuizen2020-05-181-1/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This 1) Enables core DRM syncobj support. 2) Adds options to the submission ioctl to wait/signal syncobjs. Just like the wait fence fd, this does inline waits. Using the scheduler would be nice but I believe it is out of scope for this work. Support for timeline syncobjs is implemented and the interface is ready for it, but I'm not enabling it yet until there is some code for turnip to use it. The reset is mostly in there because in the presence of waiting and signalling the same semaphores, resetting them after signalling can become very annoying. v2: - Fixed style issues - Removed a cleanup issue in a failure case - Moved to a copy_from_user per syncobj v3: - Fixed a missing declaration introduced in v2 - Reworked to use ERR_PTR/PTR_ERR - Simplified failure gotos. Used by: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2769 Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
* drm/msm/gpu: Add submit queue queriesJordan Crouse2019-04-191-0/+12
| | | | | | | | | | | | | | | | Add the capability to query information from a submit queue. The first available parameter is for querying the number of GPU faults (hangs) that can be attributed to the queue. This is useful for implementing context robustness. A user context can regularly query the number of faults to see if it is responsible for any and if so it can invalidate itself. This is also helpful for testing by confirming to the user driver if a particular command stream caused a fault (or not as the case may be). Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
* drm/msm: add param to retrieve # of GPU faults (global)Rob Clark2019-04-191-0/+1
| | | | | | | | | For KHR_robustness, userspace wants to know two things, the count of GPU faults globally, and the count of faults attributed to a given context. This patch providees the former, and the next patch provides the latter. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
* drm/msm/gpu: add per-process pagetables paramRob Clark2019-04-191-0/+1
| | | | | | | | | | | For now it always returns '0' (false), but once the iommu work is in place to enable per-process pagetables we can update the value returned. Userspace needs to know this to make an informed decision about exposing KHR_robustness. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
* drm/msm: add uapi to get/set debug nameRob Clark2018-12-111-0/+2
| | | | | | Add UAPI to get/set GEM objects' debug name. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: rework GEM_INFO ioctlRob Clark2018-12-111-5/+13
| | | | | | Prep work to add a way to get/set the GEM objects debug name. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm/gpu: add submit flag to hint which buffers should be dumpedRob Clark2018-12-111-1/+4
| | | | | | | | | | | | To lower CPU overhead, future userspace will be switching to pinning iova and avoiding the use of relocs, and only include cmds table entries for IB1 level cmdstream (but not IB2 or state-groups). This leaves the kernel unsure what to dump for rd/hangrd cmdstream dumping. So add a MSM_SUBMIT_BO_DUMP flag so userspace can indicate buffers that contain cmdstream (or are otherwise important to dump). Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: add sudo flag to submit ioctlRob Clark2018-02-201-0/+2
| | | | | | | | | | | | This flags cause cmdstream to be executed from the ringbuffer (RB) instead of IB1. Normally not something you'd ever want to do, but it is super useful for firmware debugging. Hidden behind CAP_SYS_RAWIO and a default=n kconfig option which depends on EXPERT (and has a suitably scary warning), to prevent it from being used on accident. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: Add a parameter query for the number of ringbuffersJordan Crouse2017-10-281-0/+1
| | | | | | | | | In order to manage ringbuffer priority to its fullest userspace should know how many ringbuffers it has to work with. Add a parameter to return the number of active rings. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: Support multiple ringbuffersJordan Crouse2017-10-281-0/+1
| | | | | | | | | | | | | | | | | | | | Add the infrastructure to support the idea of multiple ringbuffers. Assign each ringbuffer an id and use that as an index for the various ring specific operations. The biggest delta is to support legacy fences. Each fence gets its own sequence number but the legacy functions expect to use a unique integer. To handle this we return a unique identifier for each submission but map it to a specific ring/sequence under the covers. Newer users use a dma_fence pointer anyway so they don't care about the actual sequence ID or ring. The actual mechanics for multiple ringbuffers are very target specific so this code just allows for the possibility but still only defines one ringbuffer for each target family. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: Add per-instance submit queuesJordan Crouse2017-10-281-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the behavior of a command stream is provided by the user application during submission and the application is expected to internally maintain the settings for each 'context' or 'rendering queue' and specify the correct ones. This works okay for simple cases but as applications become more complex we will want to set context specific flags and do various permission checks to allow certain contexts to enable additional privileges. Add kernel-side submit queues to be analogous to 'contexts' or 'rendering queues' on the application side. Each file descriptor instance will maintain its own list of queues. Queues cannot be shared between file descriptors. For backwards compatibility context id '0' is defined as a default context specifying no priority and no special flags. This is intended to be the usual configuration for 99% of applications so that a garden variety application can function correctly without creating a queue. Only those applications requiring the specific benefit of different queues need create one. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: Remove __user from __u64 data typesJordan Crouse2017-08-011-3/+3
| | | | | | | | __user should be used to identify user pointers and not __u64 variables containing pointers. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: Add hint to DRM_IOCTL_MSM_GEM_INFO to return an object IOVAJordan Crouse2017-06-161-2/+6
| | | | | | | | | | | Modify the 'pad' member of struct drm_msm_gem_info to 'flags'. If the user sets 'flags' to non-zero it means that they want a IOVA for the GEM object instead of a mmap() offset. Return the iova in the 'offset' member. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> [robclark: s/hint/flags in commit msg] Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: Remove DRM_MSM_NUM_IOCTLSJordan Crouse2017-06-161-1/+0
| | | | | | | | | | The ioctl array is sparsely populated but the compiler will make sure that it is sufficiently sized for all the values that we have so we can safely use ARRAY_SIZE() instead of having a constantly changing #define in the uapi header. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: Add MSM_PARAM_GMEM_BASEJordan Crouse2017-04-081-0/+1
| | | | | | | | User space needs to know where the GMEM whole starts so that they can set up the addressing correctly. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: update uapi header licenseRob Clark2016-11-261-9/+16
| | | | | | | | | | | | | The same file in libdrm is, as is the tradition with the rest of libdrm, etc, using an MIT license. To avoid complications in the future with sync'ing the uapi header to libdrm, lets fix the license mismatch now before there are any non-trivial commits from someone other than myself. Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Gabriel Laskar <gabriel@lse.epita.fr> Cc: Mikko Rapeli <mikko.rapeli@iki.fi> Signed-off-by: Rob Clark <robdclark@gmail.com> Acked-by: Emil Velikov <emil.l.velikov@gmail.com>
* drm/msm: submit support for out-fencesRob Clark2016-09-151-1/+3
| | | | Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: submit support for in-fencesRob Clark2016-09-151-2/+7
| | | | Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: extend the submit ioctl to pass in flagsRob Clark2016-09-151-1/+14
| | | | | | | | | | | | | | We'll want to be able to pass in flags, such as asking for explicit fencing, and possibly other things down the road. Fortunately we don't need a full 32b for the pipe-id. So use the upper 16 bits for flags (which could be extended or reduced later if needed, so start adding flags from the high bits). Since anything with the upper bits set would not be a valid pipe-id, an old userspace would not set any of the upper bits, and an old kernel would reject it as an invalid pipe-id. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: add madvise ioctlRob Clark2016-07-161-1/+24
| | | | | | | Doesn't do anything too interesting until we wire up shrinker. Pretty much lifted from i915. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: add extern C guard for the UAPI headerEmil Velikov2016-05-131-0/+8
| | | | | Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Acked-by: Rob Clark <robdclark@gmail.com> (over irc)
* drm/msm: add timestamp paramRob Clark2016-03-031-0/+1
| | | | | | | | | | | | | | We need this for GL_TIMESTAMP queries. Note: currently only supported on a4xx.. a3xx doesn't have this always-on counter. I think we could emulate it with the one CP counter that is available, but for now it is of limited usefulness on a3xx (since we can't seem to do time-elapsed queries in any sane way with the existing firmware on a3xx, and if you are trying to do profiling on a tiler you want time-elapsed). We can add that later if it becomes useful. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: add max-freq gpu param to uapiRob Clark2016-02-111-0/+1
| | | | | | | | | | | | We need this in userspace for interpreting some of the perf ctrs. Note possibly not quite sufficient if we had some frequency mgmt approach other than race-to-idle. Not really sure what the best thing to do if we did. Although displaying results as a percentage of max frequence seems sensible(ish) if we did. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/msm: trivial whitespace fixRob Clark2015-12-141-1/+1
| | | | Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm: fix inclusion of drm.h in msm_drm.hGabriel Laskar2015-12-101-2/+1
| | | | | | | | | | | Using `#include "drm.h"` instead of `#include <drm/drm.h>` allow drm headers to be moved in another directory without changes, like for the libdrm imports. Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> CC: Emil Velikov <emil.l.velikov@gmail.com> CC: Mikko Rapeli <mikko.rapeli@iki.fi>
* drm/msm: use __s32, __s64, __u32 and __u64 from linux/types.h for uabiMikko Rapeli2015-06-111-38/+38
| | | | | | | | | Fixes userspace compilation errors like: error: unknown type name ‘uint32_t’ Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi> Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: validate flags, etcRob Clark2014-03-311-0/+11
| | | | | | | | | | | | | | | | After reading a nice article on LWN[1], I went back and double checked my handling of invalid-input checking. Turns out there were a couple places I had missed. Since the driver is fairly young, and the devices it supports are really only just barely usable for basic stuff (serial console) with an upstream kernel, I think we should fix this now and revert specific parts of this patch later in the unlikely event that a regression is reported. [1] https://lwn.net/Articles/588444/ Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: add chip-id paramRob Clark2014-03-311-0/+1
| | | | | | | | Some of the w/a or different behavior of userspace blob driver seem to be keyed to gpu patch revision, rather than gpu-id. So expose the full chip-id to userspace so it can DTRT. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: add a3xx gpu supportRob Clark2013-08-241-0/+207
Add initial support for a3xx 3d core. So far, with hardware that I've seen to date, we can have: + zero, one, or two z180 2d cores + a3xx or a2xx 3d core, which share a common CP (the firmware for the CP seems to implement some different PM4 packet types but the basics of cmdstream submission are the same) Which means that the eventual complete "class" hierarchy, once support for all past and present hw is in place, becomes: + msm_gpu + adreno_gpu + a3xx_gpu + a2xx_gpu + z180_gpu This commit splits out the parts that will eventually be common between a2xx/a3xx into adreno_gpu, and the parts that are even common to z180 into msm_gpu. Note that there is no cmdstream validation required. All memory access from the GPU is via IOMMU/MMU. So as long as you don't map silly things to the GPU, there isn't much damage that the GPU can do. Signed-off-by: Rob Clark <robdclark@gmail.com>