1. 15 Oct, 2021 21 commits
  2. 12 Oct, 2021 13 commits
  3. 01 Oct, 2021 6 commits
    • Arnd Bergmann's avatar
      drm/msm/submit: fix overflow check on 64-bit architectures · 95c58291
      Arnd Bergmann authored
      The overflow check does causes a warning from clang-14 when 'sz' is a type
      that is smaller than size_t:
      
      drivers/gpu/drm/msm/msm_gem_submit.c:217:10: error: result of comparison of constant 18446744073709551615 with expression of type 'unsigned int' is always false [-Werror,-Wtautological-constant-out-of-range-compare]
                      if (sz == SIZE_MAX) {
      
      Change the type accordingly.
      
      Fixes: 20224d71 ("drm/msm/submit: Move copy_from_user ahead of locking bos")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarStephen Boyd <swboyd@chromium.org>
      Link: https://lore.kernel.org/r/20210927113632.3849987-1-arnd@kernel.orgSigned-off-by: default avatarRob Clark <robdclark@chromium.org>
      95c58291
    • Rob Clark's avatar
      drm/msm: One sched entity per process per priority · 68002469
      Rob Clark authored
      Some userspace apps make assumptions that rendering against multiple
      contexts within the same process (from the same thread, with appropriate
      MakeCurrent() calls) provides sufficient synchronization without any
      external synchronization (ie. glFenceSync()/glWaitSync()).  Since a
      submitqueue maps to a gl/vk context, having multiple sched entities of
      the same priority only works with implicit sync enabled.
      
      To fix this, limit things to a single sched entity per priority level
      per process.
      
      An alternative would be sharing submitqueues between contexts in
      userspace, but tracking of per-context faults (ie. GL_EXT_robustness)
      is already done at the submitqueue level, so this is not an option.
      Signed-off-by: default avatarRob Clark <robdclark@chromium.org>
      68002469
    • Rob Clark's avatar
      drm/msm: A bit more docs + cleanup · 4cd82aa3
      Rob Clark authored
      msm_file_private is more gpu related, and in the next commit it will
      need access to other GPU specific #defines.  While we're at it, add
      some comments.
      Signed-off-by: default avatarRob Clark <robdclark@chromium.org>
      4cd82aa3
    • Rob Clark's avatar
      drm/msm/a6xx: Track current ctx by seqno · 14eb0cb4
      Rob Clark authored
      In theory a context can be destroyed and a new one allocated at the same
      address, making the pointer comparision to detect when we don't need to
      update the current pagetables invalid.  Instead assign a sequence number
      to each context on creation, and use this for the check.
      
      Fixes: 84c31ee1 ("drm/msm/a6xx: Add support for per-instance pagetables")
      Signed-off-by: default avatarRob Clark <robdclark@chromium.org>
      14eb0cb4
    • Rob Clark's avatar
      drm/msm/a6xx: Serialize GMU communication · f6f59072
      Rob Clark authored
      I've seen some crashes in our crash reporting that *look* like multiple
      threads stomping on each other while communicating with GMU.  So wrap
      all those paths in a lock.
      Signed-off-by: default avatarRob Clark <robdclark@chromium.org>
      f6f59072
    • Rob Clark's avatar
      drm/msm: Fix crash on dev file close · 654e9c18
      Rob Clark authored
      If the device file was opened prior to fw being available (such as from
      initrd before rootfs is mounted, when the initrd does not contain GPU
      fw), that would cause a later crash when the dev file is closed due to
      unitialized submitqueues list:
      
         CPU: 4 PID: 263 Comm: plymouthd Tainted: G        W         5.15.0-rc2-next-20210924 #2
         Hardware name: LENOVO 81JL/LNVNB161216, BIOS 9UCN33WW(V2.06) 06/ 4/2019
         pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
         pc : msm_submitqueue_close+0x30/0x190 [msm]
         lr : msm_postclose+0x54/0xf0 [msm]
         sp : ffff80001074bb80
         x29: ffff80001074bb80 x28: ffff03ad80c4db80 x27: ffff03ad80dc5ab0
         x26: 0000000000000000 x25: ffff03ad80dc5af8 x24: ffff03ad81e90800
         x23: 0000000000000000 x22: ffff03ad81e90800 x21: ffff03ad8b35e788
         x20: ffff03ad81e90878 x19: 0000000000000000 x18: 0000000000000000
         x17: 0000000000000000 x16: ffffda15f14f7940 x15: 0000000000000000
         x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000040
         x11: 0000000000000000 x10: 0000000000000000 x9 : ffffda15cd18ff88
         x8 : ffff03ad80c4db80 x7 : 0000000000000228 x6 : 0000000000000000
         x5 : 1793a4e807e636bd x4 : ffff03ad80c4db80 x3 : ffff03ad81e90878
         x2 : 0000000000000000 x1 : ffff03ad80c4db80 x0 : 0000000000000000
         Call trace:
          msm_submitqueue_close+0x30/0x190 [msm]
          msm_postclose+0x54/0xf0 [msm]
          drm_file_free.part.0+0x1cc/0x2e0 [drm]
          drm_close_helper.isra.0+0x74/0x84 [drm]
          drm_release+0x78/0x120 [drm]
          __fput+0x78/0x23c
          ____fput+0x1c/0x30
          task_work_run+0xcc/0x22c
          do_exit+0x304/0x9f4
          do_group_exit+0x44/0xb0
          __wake_up_parent+0x0/0x3c
          invoke_syscall+0x50/0x120
          el0_svc_common.constprop.0+0x4c/0xf4
          do_el0_svc+0x30/0x9c
          el0_svc+0x20/0x60
          el0t_64_sync_handler+0xe8/0xf0
          el0t_64_sync+0x1a0/0x1a4
         Code: aa0003f5 a90153f3 f8408eb3 aa1303e0 (f85e8674)
         ---[ end trace 39b2fa37509a2be2 ]---
         Fixing recursive fault but reboot is needed!
      
      Fixes: 86c2a0f0 drm/msm: ("Small submitqueue creation cleanup")
      Reported-by: default avatarSteev Klimaszewski <steev@kali.org>
      Signed-off-by: default avatarRob Clark <robdclark@chromium.org>
      654e9c18