1. 20 2月, 2018 1 次提交
    • R
      drm/msm: add sudo flag to submit ioctl · 6a8bd08d
      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>
      6a8bd08d
  2. 28 10月, 2017 3 次提交
    • J
      drm/msm: Add a parameter query for the number of ringbuffers · a6e29a0e
      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>
      a6e29a0e
    • J
      drm/msm: Support multiple ringbuffers · f97decac
      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>
      f97decac
    • J
      drm/msm: Add per-instance submit queues · f7de1545
      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>
      f7de1545
  3. 02 8月, 2017 1 次提交
  4. 16 6月, 2017 2 次提交
  5. 08 4月, 2017 1 次提交
  6. 27 11月, 2016 1 次提交
    • R
      drm/msm: update uapi header license · 7f6337ff
      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>
      7f6337ff
  7. 16 9月, 2016 3 次提交
  8. 16 7月, 2016 1 次提交
  9. 13 5月, 2016 1 次提交
  10. 04 3月, 2016 1 次提交
    • R
      drm/msm: add timestamp param · 6c77d1ab
      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>
      6c77d1ab
  11. 11 2月, 2016 1 次提交
  12. 15 12月, 2015 1 次提交
  13. 10 12月, 2015 1 次提交
  14. 12 6月, 2015 1 次提交
  15. 31 3月, 2014 2 次提交
    • R
      drm/msm: validate flags, etc · 93ddb0d3
      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>
      93ddb0d3
    • R
      drm/msm: add chip-id param · 4e1cbaa3
      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>
      4e1cbaa3
  16. 25 8月, 2013 1 次提交
    • R
      drm/msm: add a3xx gpu support · 7198e6b0
      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>
      7198e6b0