- 20 2月, 2018 1 次提交
-
-
由 Rob Clark 提交于
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: NRob Clark <robdclark@gmail.com>
-
- 28 10月, 2017 3 次提交
-
-
由 Jordan Crouse 提交于
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: NJordan Crouse <jcrouse@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Jordan Crouse 提交于
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: NJordan Crouse <jcrouse@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Jordan Crouse 提交于
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: NJordan Crouse <jcrouse@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 02 8月, 2017 1 次提交
-
-
由 Jordan Crouse 提交于
__user should be used to identify user pointers and not __u64 variables containing pointers. Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 16 6月, 2017 2 次提交
-
-
由 Jordan Crouse 提交于
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: NJordan Crouse <jcrouse@codeaurora.org> [robclark: s/hint/flags in commit msg] Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Jordan Crouse 提交于
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: NJordan Crouse <jcrouse@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 08 4月, 2017 1 次提交
-
-
由 Jordan Crouse 提交于
User space needs to know where the GMEM whole starts so that they can set up the addressing correctly. Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 27 11月, 2016 1 次提交
-
-
由 Rob Clark 提交于
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: NRob Clark <robdclark@gmail.com> Acked-by: NEmil Velikov <emil.l.velikov@gmail.com>
-
- 16 9月, 2016 3 次提交
-
-
由 Rob Clark 提交于
Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
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: NRob Clark <robdclark@gmail.com>
-
- 16 7月, 2016 1 次提交
-
-
由 Rob Clark 提交于
Doesn't do anything too interesting until we wire up shrinker. Pretty much lifted from i915. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 13 5月, 2016 1 次提交
-
-
由 Emil Velikov 提交于
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com> Acked-by: Rob Clark <robdclark@gmail.com> (over irc)
-
- 04 3月, 2016 1 次提交
-
-
由 Rob Clark 提交于
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: NRob Clark <robdclark@gmail.com>
-
- 11 2月, 2016 1 次提交
-
-
由 Rob Clark 提交于
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: NRob Clark <robdclark@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 15 12月, 2015 1 次提交
-
-
由 Rob Clark 提交于
Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 10 12月, 2015 1 次提交
-
-
由 Gabriel Laskar 提交于
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: NGabriel Laskar <gabriel@lse.epita.fr> Reviewed-by: NEmil Velikov <emil.l.velikov@gmail.com> CC: Emil Velikov <emil.l.velikov@gmail.com> CC: Mikko Rapeli <mikko.rapeli@iki.fi>
-
- 12 6月, 2015 1 次提交
-
-
由 Mikko Rapeli 提交于
Fixes userspace compilation errors like: error: unknown type name ‘uint32_t’ Signed-off-by: NMikko Rapeli <mikko.rapeli@iki.fi> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 31 3月, 2014 2 次提交
-
-
由 Rob Clark 提交于
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: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
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: NRob Clark <robdclark@gmail.com>
-
- 25 8月, 2013 1 次提交
-
-
由 Rob Clark 提交于
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: NRob Clark <robdclark@gmail.com>
-