Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33 |
|
#
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
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>
show more ...
|
Revision tags: v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45 |
|
#
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.
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>
show more ...
|
Revision tags: v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33 |
|
#
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, w
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
show more ...
|
Revision tags: v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1 |
|
#
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.ko
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
show more ...
|
Revision tags: v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24 |
|
#
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 decla
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>
show more ...
|
Revision tags: v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17, v4.16, v4.15, v4.13.16, v4.14 |
|
#
38c4a4cf |
| 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,
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>
show more ...
|
#
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
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>
show more ...
|
#
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 t
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>
show more ...
|
#
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 con
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>
show more ...
|
#
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
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>
show more ...
|
#
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
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>
show more ...
|
#
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 <
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/
show more ...
|
#
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@pengutroni
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>
show more ...
|
#
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 Veliko
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
show more ...
|
#
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@pengut
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>
show more ...
|
#
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 et
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>
show more ...
|
#
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 chan
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>
show more ...
|
#
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 with
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>
show more ...
|
#
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
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>
show more ...
|
#
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 b
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>
show more ...
|
#
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
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>
show more ...
|
#
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.
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>
show more ...
|
#
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 S
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>
show more ...
|
#
ef146c00 |
| 24-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
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>
show more ...
|