kernel.git/drivers/gpu/drm/etnaviv/etnaviv_buffer.c, branch linux-rolling-lts

drm/etnaviv: fix flush sequence logic

2025-11-13T20:33:58Z

[ Upstream commit a042beac6e6f8ac1e923784cfff98b47cbabb185 ] The current logic uses the flush sequence from the current address space. This is harmless when deducing the flush requirements for the current submit, as either the incoming address space is the same one as the currently active one or we switch context, in which case the flush is unconditional. However, this sequence is also stored as the current flush sequence of the GPU. If we switch context the stored flush sequence will no longer belong to the currently active address space. This incoherency can then cause missed flushes, resulting in translation errors. Fixes: 27b67278e007 ("drm/etnaviv: rework MMU handling") Signed-off-by: Tomeu Vizoso Signed-off-by: Lucas Stach Reviewed-by: Christian Gmeiner Link: https://lore.kernel.org/r/20251021093723.3887980-1-l.stach@pengutronix.de Signed-off-by: Sasha Levin

drm/etnaviv: flush shader L1 cache after user commandstream

2024-12-09T09:41:13Z

commit 4f8dbadef085ab447a01a8d4806a3f629fea05ed upstream. The shader L1 cache is a writeback cache for shader loads/stores and thus must be flushed before any BOs backing the shader buffers are potentially freed. Cc: stable@vger.kernel.org Reviewed-by: Christian Gmeiner Signed-off-by: Lucas Stach Signed-off-by: Greg Kroah-Hartman

drm/etnaviv: slow down FE idle polling

2023-06-21T13:18:14Z

Currently the FE is spinning way too fast when polling for new work in the FE idleloop. As each poll fetches 16 bytes from memory, a GPU running at 1GHz with the current setting of 200 wait cycle between fetches causes 80 MB/s of memory traffic just to check for new work when the GPU is otherwise idle, which is more FE traffic than in some GPU loaded cases. Significantly increase the number of wait cycles to slow down the poll interval to ~30µs, limiting the FE idle memory traffic to 512 KB/s, while providing a max latency which should not hurt most use-cases. The FE WAIT command seems to have some unknown discrete steps in the wait cycles so we may over/undershoot the target a bit, but that should be harmless. If the GPU core base frequency is unknown keep the 200 wait cycles as a sane default. Signed-off-by: Lucas Stach Reviewed-by: Sui Jingfeng Tested-by: Sui Jingfeng Reviewed-by: Christian Gmeiner

drm/etnaviv: return context from etnaviv_iommu_context_get

2021-09-16T08:34:59Z

Being able to have the refcount manipulation in an assignment makes it much easier to parse the code. Cc: stable@vger.kernel.org # 5.4 Signed-off-by: Lucas Stach Tested-by: Michael Walle Tested-by: Marek Vasut Reviewed-by: Christian Gmeiner

drm/etnaviv: fix TS cache flushing on GPUs with BLT engine

2020-03-20T17:40:44Z

As seen in the Vivante kernel driver, most GPUs with the BLT engine have a broken TS cache flush. The workaround is to temporarily set the BLT command to CLEAR_IMAGE, without actually executing the clear. Apparently this state change is enough to trigger the required TS cache flush. As the BLT engine is completely asychronous, we also need a few more stall states to synchronize the flush with the frontend. Root-caused-by: Jonathan Marek Signed-off-by: Lucas Stach

Merge drm/drm-next into drm-misc-next

2019-10-03T14:38:50Z

We haven't done any backmerge for a while due to the merge window, and it starts to become an issue for komeda. Let's bring 5.4-rc1 in. Signed-off-by: Maxime Ripard

drm/etnaviv: use drm_debug_enabled() to check for debug categories

2019-10-02T13:29:16Z

Allow better abstraction of the drm_debug global variable in the future. No functional changes. Cc: Lucas Stach Cc: Russell King Cc: Christian Gmeiner Cc: etnaviv@lists.freedesktop.org Acked-by: Lucas Stach Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/f202f2cdd7c3176649dadeb48a6da4b208e9e829.1569329774.git.jani.nikula@intel.com

drm/etnaviv: implement per-process address spaces on MMUv2

2019-08-15T09:44:27Z

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 Reviewed-by: Philipp Zabel Reviewed-by: Guido Günther

drm/etnaviv: rework MMU handling

2019-08-15T08:56:45Z

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 Reviewed-by: Philipp Zabel Reviewed-by: Guido Günther

drm/etnaviv: replace MMU flush marker with flush sequence

2019-08-15T08:56:03Z

If a MMU is shared between multiple GPUs, all of them need to flush their TLBs, so a single marker that gets reset on the first flush won't do. Replace the flush marker with a sequence number, so that it's possible to check if the TLB is in sync with the current page table state for each GPU. Signed-off-by: Lucas Stach Reviewed-by: Philipp Zabel Reviewed-by: Guido Günther