summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/msm/msm_submitqueue.c
AgeCommit message (Collapse)Author
2022-08-27drm/msm: Split out idr_lockRob Clark
Otherwise if we hit reclaim pinning objects in the submit path, we'll be blocking retire_worker trying to free a submit. Signed-off-by: Rob Clark <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/496116/ Link: https://lore.kernel.org/r/20220802155152.1727594-4-robdclark@gmail.com
2022-04-21drm/msm: Add a way to override processes comm/cmdlineRob Clark
In the cause of using the GPU via virtgpu, the host side process is really a sort of proxy, and not terribly interesting from the PoV of crash/fault logging. Add a way to override these per process so that we can see the guest process's name. v2: Handle kmalloc failure, add comment to explain kstrdup returns NULL if passed NULL [Dan Carpenter] Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20220317165144.222101-4-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2022-03-04drm/msm: Add SYSPROF param (v2)Rob Clark
Add a SYSPROF param for system profiling tools like Mesa's pps-producer (perfetto) to control behavior related to system-wide performance counter collection. In particular, for profiling, one wants to ensure that GPU context switches do not effect perfcounter state, and might want to suppress suspend (which would cause counters to lose state). v2: Swap the order in msm_file_private_set_sysprof() [sboyd] and initialize the sysprof_active refcount to one (because the under/ overflow checking in refcount_t doesn't expect a 0->1 transition) meaning that values greater than 1 means sysprof is active. Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20220304005317.776110-4-robdclark@gmail.com
2021-10-15drm/msm: unlock on error in get_sched_entity()Dan Carpenter
Add a missing unlock on the error path if drm_sched_entity_init() fails. Fixes: 68002469e571 ("drm/msm: One sched entity per process per priority") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20211011124005.GE15188@kili Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-01drm/msm: One sched entity per process per priorityRob Clark
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: Rob Clark <robdclark@chromium.org>
2021-10-01drm/msm: Fix crash on dev file closeRob Clark
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: 86c2a0f000c1 drm/msm: ("Small submitqueue creation cleanup") Reported-by: Steev Klimaszewski <steev@kali.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-07-28drm/msm: Utilize gpu scheduler prioritiesRob Clark
The drm/scheduler provides additional prioritization on top of that provided by however many number of ringbuffers (each with their own priority level) is supported on a given generation. Expose the additional levels of priority to userspace and map the userspace priority back to ring (first level of priority) and schedular priority (additional priority levels within the ring). Signed-off-by: Rob Clark <robdclark@chromium.org> Acked-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20210728010632.2633470-13-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-07-28drm/msm: Conversion to drm schedulerRob Clark
For existing adrenos, there is one or more ringbuffer, depending on whether preemption is supported. When preemption is supported, each ringbuffer has it's own priority. A submitqueue (which maps to a gl context or vk queue in userspace) is mapped to a specific ring- buffer at creation time, based on the submitqueue's priority. Each ringbuffer has it's own drm_gpu_scheduler. Each submitqueue maps to a drm_sched_entity. And each submit maps to a drm_sched_job. Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/4 Signed-off-by: Rob Clark <robdclark@chromium.org> Acked-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20210728010632.2633470-10-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-07-27drm/msm: Track "seqno" fences by idrRob Clark
Previously the (non-fd) fence returned from submit ioctl was a raw seqno, which is scoped to the ring. But from UABI standpoint, the ioctls related to seqno fences all specify a submitqueue. We can take advantage of that to replace the seqno fences with a cyclic idr handle. This is in preperation for moving to drm scheduler, at which point the submit ioctl will return after queuing the submit job to the scheduler, but before the submit is written into the ring (and therefore before a ring seqno has been assigned). Which means we need to replace the dma_fence that userspace may need to wait on with a scheduler fence. Signed-off-by: Rob Clark <robdclark@chromium.org> Acked-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20210728010632.2633470-8-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-07-27drm/msm: Small submitqueue creation cleanupRob Clark
If we don't have a gpu, there is no need to create a submitqueue, which lets us simplify the error handling and submitqueue creation. Signed-off-by: Rob Clark <robdclark@chromium.org> Acked-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20210728010632.2633470-3-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-07-27drm/msm: Docs and misc cleanupRob Clark
Fix a couple incorrect or misspelt comments, and add submitqueue doc comment. Signed-off-by: Rob Clark <robdclark@chromium.org> Acked-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20210728010632.2633470-2-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2020-09-12drm/msm: Add a context pointer to the submitqueueJordan Crouse
Each submitqueue is attached to a context. Add a pointer to the context to the submitqueue at create time and refcount it so that it stays around through the life of the queue. Co-developed-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-09-12drm/msm: Remove dangling submitqueue referencesRob Clark
Currently it doesn't matter, since we free the ctx immediately. But when we start refcnt'ing the ctx, we don't want old dangling list entries to hang around. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-06-11drm/msm: fix potential memleak in error branchBernard Zhao
In function msm_submitqueue_create, the queue is a local variable, in return -EINVAL branch, queue didn`t add to ctx`s list yet, and also didn`t kfree, this maybe bring in potential memleak. Signed-off-by: Bernard Zhao <bernard@vivo.com> [trivial commit msg fixup] Signed-off-by: Rob Clark <robdclark@chromium.org>
2019-09-03drm/msm: drop use of drmP.hSam Ravnborg
Drop the deprecated drmP.h header file, and trim msm_drv.h to the relevant include files. This resulted in a suprisingly many edits as many files relied on headers included via msm_drv.h. But msm_drv.h is not supposed to carry include files it do not need, so the individual files have to include what extra they needs. v2: - Rebased on top of https://gitlab.freedesktop.org/drm/msm.git msm-next Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Jordan Crouse <jcrouse@codeaurora.org> Cc: Jeykumar Sankaran <jsanka@codeaurora.org> Cc: Bruce Wang <bzwang@chromium.org> Cc: Shayenne Moura <shayenneluzmoura@gmail.com> Cc: Mamta Shukla <mamtashukla555@gmail.com> Cc: Jonathan Marek <jonathan@marek.ca> Cc: Carsten Behling <carsten.behling@googlemail.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Cc: Sibi Sankar <sibis@codeaurora.org> Cc: Todor Tomov <todor.tomov@linaro.org> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190804065551.GA5211@ravnborg.org
2019-06-05treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 284Thomas Gleixner
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 and only version 2 as published by the free software foundation this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 294 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190529141900.825281744@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-19drm/msm/gpu: Add submit queue queriesJordan Crouse
Add the capability to query information from a submit queue. The first available parameter is for querying the number of GPU faults (hangs) that can be attributed to the queue. This is useful for implementing context robustness. A user context can regularly query the number of faults to see if it is responsible for any and if so it can invalidate itself. This is also helpful for testing by confirming to the user driver if a particular command stream caused a fault (or not as the case may be). Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2017-10-28drm/msm: Support multiple ringbuffersJordan 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: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-10-28drm/msm: Add per-instance submit queuesJordan 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: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>