1. 02 8月, 2017 1 次提交
  2. 17 6月, 2017 1 次提交
  3. 16 6月, 2017 4 次提交
  4. 08 4月, 2017 7 次提交
  5. 04 4月, 2017 1 次提交
  6. 07 2月, 2017 1 次提交
  7. 13 1月, 2017 1 次提交
  8. 30 12月, 2016 1 次提交
    • J
      drm/msm: Ensure that the hardware write pointer is valid · 88b333b0
      Jordan Crouse 提交于
      Currently the value written to CP_RB_WPTR is calculated on the fly as
      (rb->next - rb->start). But as the code is designed rb->next is wrapped
      before writing the commands so if a series of commands happened to
      fit perfectly in the ringbuffer, rb->next would end up being equal to
      rb->size / 4 and thus result in an out of bounds address to CP_RB_WPTR.
      
      The easiest way to fix this is to mask WPTR when writing it to the
      hardware; it makes the hardware happy and the rest of the ringbuffer
      math appears to work and there isn't any point in upsetting anything.
      Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
      [squash in is_power_of_2() check]
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      88b333b0
  9. 29 11月, 2016 5 次提交
  10. 28 11月, 2016 1 次提交
  11. 16 7月, 2016 2 次提交
  12. 05 6月, 2016 1 次提交
  13. 08 5月, 2016 4 次提交
  14. 04 3月, 2016 3 次提交
  15. 11 2月, 2016 1 次提交
  16. 12 6月, 2015 3 次提交
  17. 15 5月, 2015 1 次提交
    • R
      drm/msm: fix locking inconsistencies in gpu->destroy() · 774449eb
      Rob Clark 提交于
      In error paths, this was being called without struct_mutex held.
      Leading to panics like:
      
        msm 1a00000.qcom,mdss_mdp: No memory protection without IOMMU
        Kernel panic - not syncing: BUG!
        CPU: 0 PID: 1409 Comm: cat Not tainted 4.0.0-dirty #4
        Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
        Call trace:
        [<ffffffc000089c78>] dump_backtrace+0x0/0x118
        [<ffffffc000089da0>] show_stack+0x10/0x20
        [<ffffffc0006686d4>] dump_stack+0x84/0xc4
        [<ffffffc0006678b4>] panic+0xd0/0x210
        [<ffffffc0003e1ce4>] drm_gem_object_free+0x5c/0x60
        [<ffffffc000402870>] adreno_gpu_cleanup+0x60/0x80
        [<ffffffc0004035a0>] a3xx_destroy+0x20/0x70
        [<ffffffc0004036f4>] a3xx_gpu_init+0x84/0x108
        [<ffffffc0004018b8>] adreno_load_gpu+0x58/0x190
        [<ffffffc000419dac>] msm_open+0x74/0x88
        [<ffffffc0003e0a48>] drm_open+0x168/0x400
        [<ffffffc0003e7210>] drm_stub_open+0xa8/0x118
        [<ffffffc0001a0e84>] chrdev_open+0x94/0x198
        [<ffffffc000199f88>] do_dentry_open+0x208/0x310
        [<ffffffc00019a4c4>] vfs_open+0x44/0x50
        [<ffffffc0001aa26c>] do_last.isra.14+0x2c4/0xc10
        [<ffffffc0001aac38>] path_openat+0x80/0x5e8
        [<ffffffc0001ac354>] do_filp_open+0x2c/0x98
        [<ffffffc00019b60c>] do_sys_open+0x13c/0x228
        [<ffffffc00019b72c>] SyS_openat+0xc/0x18
        CPU1: stopping
      
      But there isn't any particularly good reason to hold struct_mutex for
      teardown, so just standardize on calling it without the mutex held and
      use the _unlocked() versions for GEM obj unref'ing
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      774449eb
  18. 17 12月, 2014 1 次提交
  19. 17 11月, 2014 1 次提交