#
f098f9b8 |
|
07-Jun-2023 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: move runtime PM handling to events Conceptually events are the right abstraction to handle the GPU runtime PM state: as long as any event is pending the GPU can not be idle. Events are also properly freed and reallocated when the GPU has been reset after a hang. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
|
#
f51d753f |
|
03-Jun-2022 |
Christian Gmeiner <christian.gmeiner@gmail.com> |
drm/etnaviv: print offender task information on hangcheck recovery Track the pid per submit, so we can print the name and cmdline of the task which submitted the batch that caused the gpu to hang. Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
|
#
b827c84f |
|
31-Mar-2022 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/etnaviv: Use scheduler dependency handling We need to pull the drm_sched_job_init much earlier, but that's very minor surgery. v2: Actually fix up cleanup paths by calling drm_sched_job_init, which I wanted to to in the previous round (and did, for all other drivers). Spotted by Lucas. v3: Rebase over renamed functions to add dependencies. v4: Rebase over patches from Christian. v5: More rebasing over work from Christian. Acked-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@armlinux.org.uk> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Cc: etnaviv@lists.freedesktop.org Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Link: https://patchwork.freedesktop.org/patch/msgid/20220331204651.2699107-2-daniel.vetter@ffwll.ch
|
#
0941a4e3 |
|
03-Nov-2021 |
Christian König <christian.koenig@amd.com> |
drm/etnaviv: stop using dma_resv_excl_fence v2 We can get the excl fence together with the shared ones as well. v2: rename the member to fences as well Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@armlinux.org.uk> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: etnaviv@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20220321135856.1331-5-christian.koenig@amd.com
|
#
1442d81f |
|
05-Mar-2020 |
Gustavo A. R. Silva <gustavo@embeddedor.com> |
drm/etnaviv: Replace zero-length array with flexible-array member The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
|
#
38c4a4cf0 |
|
06-Nov-2017 |
Arnd Bergmann <arnd@arndb.de> |
drm/etnaviv: avoid deprecated timespec struct timespec is being removed from the kernel because it often leads to code that is not y2038-safe. In the etnaviv driver, monotonic timestamps are used, which do not suffer from overflow, but the usage of timespec here gets in the way of removing the interface completely. Pass down the user-supplied 64-bit value here rather than converting it to an intermediate timespec to avoid the conversion. The conversion is transparent for all regular CLOCK_MONOTONIC values, but is a small change in behavior for excessively large values: the existing code would treat e.g. tv_sec=0x100000000 the same as tv_sec=0 and not block, while the new code it would block for up to 2^31 seconds. The new behavior is more logical here, but if it causes problems, the truncation can be put back. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
#
088880dd |
|
02-Aug-2019 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: implement softpin With softpin we allow the userspace to take control over the GPU virtual address space. The new capability is relected by a bump of the minor DRM version. There are a few restrictions for userspace to take into account: 1. The kernel reserves a bit of the address space to implement zero page faulting and mapping of the kernel internal ring buffer. Userspace can query the kernel for the first usable GPU VM address via ETNAVIV_PARAM_SOFTPIN_START_ADDR. 2. We only allow softpin on GPUs, which implement proper process separation via PPAS. If softpin is not available the softpin start address will be set to ~0. 3. Softpin is all or nothing. A submit using softpin must not use any address fixups via relocs. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Guido Günther <agx@sigxcpu.org>
|
#
17eae23b |
|
02-Aug-2019 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: allow to request specific virtual address for gem mapping Allow the mapping code to request a specific virtual address for the gem mapping. If the virtual address is zero we fall back to the old mode of allocating a virtual address for the mapping. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Guido Günther <agx@sigxcpu.org>
|
#
17e4660a |
|
05-Jul-2019 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: implement per-process address spaces on MMUv2 This builds on top of the MMU contexts introduced earlier. Instead of having one context per GPU core, each GPU client receives its own context. On MMUv1 this still means a single shared pagetable set is used by all clients, but on MMUv2 there is now a distinct set of pagetables for each client. As the command fetch is also translated via the MMU on MMUv2 the kernel command ringbuffer is mapped into each of the client pagetables. As the MMU context switch is a bit of a heavy operation, due to the needed cache and TLB flushing, this patch implements a lazy way of switching the MMU context. The kernel does not have its own MMU context, but reuses the last client context for all of its operations. This has some visible impact, as the GPU can now only be started once a client has submitted some work and we got the client MMU context assigned. Also the MMU context has a different lifetime than the general client context, as the GPU might still execute the kernel command buffer in the context of a client even after the client has completed all GPU work and has been terminated. Only when the GPU is runtime suspended or switches to another clients MMU context is the old context freed up. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Guido Günther <agx@sigxcpu.org>
|
#
e6364d70 |
|
05-Jul-2019 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: provide MMU context to etnaviv_gem_mapping_get In preparation to having a context per process, etnaviv_gem_mapping_get should not use the current GPU context, but needs to be told which context to use. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Guido Günther <agx@sigxcpu.org>
|
#
27b67278 |
|
05-Jul-2019 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: rework MMU handling This reworks the MMU handling to make it possible to have multiple MMU contexts. A context is basically one instance of GPU page tables. Currently we have one set of page tables per GPU, which isn't all that clever, as it has the following two consequences: 1. All GPU clients (aka processes) are sharing the same pagetables, which means there is no isolation between clients, but only between GPU assigned memory spaces and the rest of the system. Better than nothing, but also not great. 2. Clients operating on the same set of buffers with different etnaviv GPU cores, e.g. a workload using both the 2D and 3D GPU, need to map the used buffers into the pagetable sets of each used GPU. This patch reworks all the MMU handling to introduce the abstraction of the MMU context. A context can be shared across different GPU cores, as long as they have compatible MMU implementations, which is the case for all systems with Vivante GPUs seen in the wild. As MMUv1 is not able to change pagetables on the fly, without a "stop the world" operation, which stops GPU, changes pagetables via CPU interaction, restarts GPU, the implementation introduces a shared context on MMUv1, which is returned whenever there is a request for a new context. This patch assigns a MMU context to each GPU, so on MMUv2 systems there is still one set of pagetables per GPU, but due to the shared context MMUv1 systems see a change in behavior as now a single pagetable set is used across all GPU cores. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Guido Günther <agx@sigxcpu.org>
|
#
52791eee |
|
11-Aug-2019 |
Christian König <christian.koenig@amd.com> |
dma-buf: rename reservation_object to dma_resv Be more consistent with the naming of the other DMA-buf objects. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/323401/
|
#
5e93ec4d |
|
05-Jul-2019 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: remove unused function etnaviv_gem_mapping_reference Hasn't been used for quite a while. There is no point in keeping unused code around. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Guido Günther <agx@sigxcpu.org>
|
#
c6be8086 |
|
14-Jun-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/etnaviv: Drop resv argument from etnaviv_gem_new_impl Only user was the prime import, and drm_prime.c takes care of that now. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@armlinux.org.uk> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: etnaviv@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20190614203615.12639-43-daniel.vetter@ffwll.ch
|
#
fa238ea1 |
|
02-Feb-2019 |
Rob Herring <robh@kernel.org> |
drm: etnaviv: Switch to use drm_gem_object reservation_object Now that the base struct drm_gem_object has a reservation_object, use it and remove the private BO one. Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@armlinux.org.uk> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: etnaviv@lists.freedesktop.org Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190202154158.10443-3-robh@kernel.org Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
#
72ac64b8 |
|
23-Nov-2018 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: move job context pointer to etnaviv_gem_submit The context isn't really related to the cmdbuf, but is a property of the job. This has been missed when moving to a properly refcounted etnaviv_gem_submit. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
|
#
f6ffbd4f |
|
08-May-2018 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: replace license text with SPDX tags This replaces the repetitive GPL-2.0 license text in code and header files with the SPDX tags. Generated hardware headers aren't changed, as any changes there need to be done in the upstream rnndb repository. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
|
#
683da226 |
|
04-Dec-2017 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: move dependency handling to scheduler Move the fence dependency handling to the scheduler where it belongs. Jobs with unsignaled dependencies just get to sit in the scheduler queue without holding any locks. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
|
#
e93b6dee |
|
04-Dec-2017 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: hook up DRM GPU scheduler This hooks in the DRM GPU scheduler. No improvement yet, as all the dependency handling is still done in etnaviv_gem_submit. This just replaces the actual GPU submit by passing through the scheduler. Allows to get rid of the retire worker, as this is now driven by the scheduler. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
|
#
8bc4d885 |
|
29-Nov-2017 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: track fences by IDR instead of seqno This moves away from using the internal seqno as the userspace fence reference. By moving to a generic ID, we can later replace the internal fence by something different than the etnaviv seqno fence. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
|
#
8bda1516 |
|
24-Nov-2017 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: couple runtime PM management to submit object lifetime As long as there is an active submit, we want the GPU to stay awake. This is slightly complicated by the fact that we really want to wake the GPU at the last possible moment to achieve maximum power savings. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
|
#
2f9225db |
|
24-Nov-2017 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: move cmdbuf into submit object Less dynamic allocations and slims down the cmdbuf object to only the required information, as everything else is already available in the submit object. This also simplifies buffer and mappings lifetime management, as they are now exlusively attached to the submit object and not additionally to the cmdbuf. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
|
#
797b0159 |
|
24-Nov-2017 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: move exec_state to submit object We'll need this in some places where only the submit is available. Also this is a first step at slimming down the cmdbuf object. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
|
#
ef146c00 |
|
23-Nov-2017 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: move PMRs to submit object To make them available to the event worker even after the actual command stream execution has finished. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
|
#
e0329e6c |
|
24-Nov-2017 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: refcount the submit object The submit object lifetime will get extended to the actual GPU execution. As multiple users will depend on this, add a kref to properly control destruction of the object. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
|
#
08301d73 |
|
24-Nov-2017 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: move ww_acquire_ctx out of submit object The acquire_ctx is special in that it needs to be released from the same thread as has been used to initialize it. This collides with the intention to extend the submit lifetime beyond the gem_submit function with potentially other threads doing the final cleanup. Move the ww_acquire_ctx to the function local stack as suggested in the documentation. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
|
#
9efabd73 |
|
23-Nov-2017 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: attach in fence to submit and move fence wait to fence_sync Simplifies the cleanup path and moves fence waiting to a central location. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
|
#
10009ea2 |
|
23-Nov-2017 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: rename submit fence to out_fence This is the fence passed out on a sucessful GPU submit. Make the name more clear. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
|
#
c5283723 |
|
24-Nov-2017 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: simplify submit_create Use kzalloc so other code doesn't need to worry about uninitialized members. Drop the non-standard GFP flags, as we really don't want to fail the submit when under slight memory pressure. Remove one level of indentation by using an early return if the allocation failed. Also remove the unused drm device member. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
|
#
b2295c24 |
|
17-Nov-2017 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: get rid of userptr worker All code paths which populate userptr BOs are fine with the get_pages function taking the mmap_sem lock. This allows to get rid of the pretty involved architecture with a worker being scheduled if the mmap_sem needs to be taken, but instead call GUP directly and allow it to take the lock if necessary. This simplifies the code a lot and removes the possibility of this function returning -EAGAIN, which complicates object population handling at the callers. A notable change in behavior is that we don't allow a process to populate objects with user pages from a foreign MM anymore. This would have been an invalid use before, as it breaks the assumptions made in the etnaviv kernel driver to enfore cache coherence. We now disallow this by rejecting the request to populate those objects. Well behaving userspace is unaffected by this change. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
|
#
54f09288 |
|
16-Nov-2017 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: change return type of etnaviv_gem_obj_add to void This function never fails, as it does nothing more than adding the GEM object to the global device list. Making this explicit through the void return type allows to drop some unnecessary error handling. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
|
#
f4a4381b |
|
27-Jun-2017 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: fix submit flags getting overwritten by BO content The addition of the flags member to etnaviv_gem_submit structure didn't take into account that the last member of this structure is a variable length array. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
|
#
6e2b98cf |
|
22-Mar-2017 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: return GPU fence through the submit structure The next patch will need the complete dma_fence, instead of just the seqno, to create the sync_file in etnaviv_ioctl_gem_submit, in case an out_fence_fd is requested. The submit needs to hold a reference to the dma_fence, to avoid raceing with the GPU completing the fence. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> --- New patch in v3.
|
#
9ad59fea |
|
02-Mar-2017 |
Philipp Zabel <p.zabel@pengutronix.de> |
drm/etnaviv: submit support for in-fences Loosely based on commit f0a42bb5423a ("drm/msm: submit support for in-fences"). Unfortunately, struct drm_etnaviv_gem_submit doesn't have a flags field yet, so we have to extend the structure and trust that drm_ioctl will clear the flags for us if an older userspace only submits part of the struct. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com> Reviewed-by: Sumit Semwal <sumit.semwal@linaro.org> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
|
#
a10e2bde |
|
26-Apr-2016 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: fix mmap operations for userptr and dma-buf objects Add an indirect object operations call to allow distinct implementations of the mmap operation based on the type of the object. This ensures that the exporter is called to set up the mmap for imported dma-bufs and disallows mapping of userptr objects through the DRM file, as this might lead to serious corruption of kernel internal state. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
|
#
8779aa8f |
|
21-Jan-2016 |
Russell King <rmk+kernel@arm.linux.org.uk> |
drm: etnaviv: clean up submit_bo() As we now store the etnaviv_vram_mapping, we no longer need to store the iova itself: we can get this directly from the mapping structure. Arrange for submit_bo() to return a pointer to etnaviv_gem_submit_bo, and directly access mapping->iova when applying relocations. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
|
#
b6325f40 |
|
21-Jan-2016 |
Russell King <rmk+kernel@arm.linux.org.uk> |
drm: etnaviv: clean up vram_mapping submission/retire path Currently, we scan the list of mappings each time we want to operate on the vram_mapping struct. Rather than repeatedly scanning these, look them up once in the submission path, and then use _reference and _unreference methods as necessary to manage this object. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
|
#
a0a5ab3e |
|
25-Jan-2016 |
Lucas Stach <l.stach@pengutronix.de> |
drm/etnaviv: call correct function when trying to vmap a DMABUF When trying to get the vmap address of an imported buffer, we must call into the appropriate helper function, to allow the exporter to establish the vmap, instead of trying to vmap the buffer on our own. Add an indirection through etnaviv_gem_ops to allow the correct implementation to be called. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
|
#
a8c21a54 |
|
03-Dec-2015 |
The etnaviv authors <dri-devel@lists.freedesktop.org> |
drm/etnaviv: add initial etnaviv DRM driver This adds the etnaviv DRM driver and hooks it up in Makefiles and Kconfig. Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|