kernel/linux.git/drivers/gpu/drm/etnaviv/etnaviv_buffer.c, branch linux-7.0.y

drm/etnaviv: Add PPU flop reset

2026-01-06T15:43:19+00:00

The PPU flop reset is required on some hardware to clear the temporary registers. This code follows the implementation of the PPU flop reset as found in the public galcore kernel module. Compared to that code some superfluous parts were removed and only the code path for SoC chip_model = 0x8000 and revision = 0x6205 is implemented and tested. v2: - Move flop reset data to etnaviv_drm_private and initialize it from etnaviv_gpu_bind (Lucas) - Prepare code for more chip IDs and other flop reset types - Do some cleanups and rename some functions v3: - Move initialization of flop reset data to etnaviv_gpu_init (Lucas) - Free PPU data suballocation (Lucas) v4: As suggested by - replace "asm-generic/int-ll64.h" with "linux/types.h" - drop flop reset type enum since we only support one type here - move function return parameters on same line with function name - replace open coded for loop with memset32 - add cnost to local static values - add a return value to etnaviv_flop_reset_ppu_init; handle and pass errors on to the caller - handle etnaviv_flop_reset_ppu_init return value - use dev_err for flop reset error message - fix include guard to be consistent with the other driver code - fix license header and formatting v5: As suggested by Christian Gmeiner: - add required header that is no longer pulled in by etnaviv_buffer.h - fix include style of linux headers - free flop_reset_data_ppu when command buffer initialization fails - fix typo in error message [cgmeiner: fix SPDX comment style, fix line end with a '(' and fix typo] Signed-off-by: Gert Wollny Reviewed-by: Christian Gmeiner Tested-by: Marek Vasut # STM32MP255C DHCOS DHSBC Link: https://patch.msgid.link/20251119164624.9297-5-gert.wollny@collabora.com Signed-off-by: Christian Gmeiner

drm/etnaviv: move some functions to a header to be able to use them externally

2026-01-06T15:43:18+00:00

v2: Add license info to header v3: remove unused headers (Christian Gmainer) [cgmeiner: improve include guard] Signed-off-by: Gert Wollny Reviewed-by: Christian Gmeiner Tested-by: Marek Vasut # STM32MP255C DHCOS DHSBC Link: https://patch.msgid.link/20251119164624.9297-3-gert.wollny@collabora.com Signed-off-by: Christian Gmeiner

Merge tag 'v6.18-rc6' into drm-next

2025-11-20T22:55:08+00:00

Linux 6.18-rc6 Backmerge in order to merge msm next Signed-off-by: Dave Airlie

drm: include drm_print.h where needed

2025-10-31T08:34:52+00:00

There are a gazillion files that depend on drm_print.h being indirectly included via drm_buddy.h, drm_mm.h, or ttm/ttm_resource.h. In preparation for removing those includes, explicitly include drm_print.h where needed. Cc: Thomas Zimmermann Reviewed-by: Thomas Zimmermann Signed-off-by: Jani Nikula Link: https://lore.kernel.org/r/5fe67395907be33eb5199ea6d540e29fddee71c8.1761734313.git.jani.nikula@intel.com

drm/etnaviv: fix flush sequence logic

2025-10-27T21:47:09+00:00

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

drm/etnaviv: flush shader L1 cache after user commandstream

2024-10-28T15:49:09+00:00

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

drm/etnaviv: slow down FE idle polling

2023-06-21T13:18:14+00:00

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:59+00:00

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:44+00:00

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:50+00:00

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