1. 12 9月, 2013 2 次提交
  2. 11 9月, 2013 2 次提交
    • R
      drm/msm: hangcheck harder · 26791c48
      Rob Clark 提交于
      If gpu locks up with the rptr shortly beyond the wrap-around point in
      the ringbuffer, because the rptr was not reset (but wptr is, by virtue
      of resetting rb->cur), we could end up in a scenario where we think
      there is not enough space in the ringbuffer for the next cmds.  And
      since the CP won't reset rptr until after processing an IB, this leaves
      things in a sort of deadlock.
      
      So reset rptr too.  And a bit more spiffing up of hangcheck to make
      things easier to debug.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      26791c48
    • R
      drm/msm: handle read vs write fences · bf6811f3
      Rob Clark 提交于
      The userspace API already had everything needed to handle read vs write
      synchronization.  This patch actually bothers to hook it up properly, so
      that we don't need to (for example) stall on userspace read access to a
      buffer that gpu is also still reading.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      bf6811f3
  3. 25 8月, 2013 2 次提交
    • R
      drm/msm: add basic hangcheck/recovery mechanism · bd6f82d8
      Rob Clark 提交于
      A basic, no-frills recovery mechanism in case the gpu gets wedged.  We
      could try to be a bit more fancy and restart the next submit after the
      one that got wedged, but for now keep it simple.  This is enough to
      recover things if, for example, the gpu hangs mid way through a piglit
      run.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      bd6f82d8
    • 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