The flush callback may be called on the same pipe context, and thus
the same stream, from two different threads of execution. However,
etna_cmd_stream_flush{,2}() must not be called on the same stream
from two different threads of execution as that would mess up the
etna_bo refcounting and likely have other ugly side effects.
Fix this by using a reentrant screen lock around the flush callback.
Signed-off-by: Marek Vasut <ma...@denx.de>
Cc: Christian Gmeiner <christian.gmei...@gmail.com>
Cc: Lucas Stach <l.st...@pengutronix.de>
---
src/gallium/drivers/etnaviv/etnaviv_context.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.c
b/src/gallium/drivers/etnaviv/etnaviv_context.c
index a59338490b6..ab6b2d5e154 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_context.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_context.c
@@ -310,8 +310,11 @@ etna_flush(struct pipe_context *pctx, struct
pipe_fence_handle **fence,
enum pipe_flush_flags flags)
{
struct etna_context *ctx = etna_context(pctx);
+ struct etna_screen *screen = ctx->screen;
int out_fence_fd = -1;
+ mtx_lock(&screen->lock);
+
list_for_each_entry(struct etna_hw_query, hq, &ctx->active_hw_queries, node)
etna_hw_query_suspend(hq, ctx);
@@ -324,6 +327,8 @@ etna_flush(struct pipe_context *pctx, struct
pipe_fence_handle **fence,
if (fence)
*fence = etna_fence_create(pctx, out_fence_fd);
+
+ mtx_unlock(&screen->lock);
}
static void
--
2.20.1
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
