On 16/11/2022 13:18, Philipp Zabel wrote:
On Fri, Sep 16, 2022 at 05:12:04PM +0200, Lucas Stach wrote:
Allows to easily track if several fd are pointing to the same
execution context due to being dup'ed.
Signed-off-by: Lucas Stach <l.st...@pengutronix.de>
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 3 +++
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 1d2b4fb4bcf8..b69edb40ae2a 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -49,6 +49,7 @@ static void load_gpu(struct drm_device *dev)
static int etnaviv_open(struct drm_device *dev, struct drm_file *file)
{
struct etnaviv_drm_private *priv = dev->dev_private;
+ static atomic_t ident = ATOMIC_INIT(0);
struct etnaviv_file_private *ctx;
int ret, i;
@@ -56,6 +57,8 @@ static int etnaviv_open(struct drm_device *dev, struct drm_file *file)
if (!ctx)
return -ENOMEM;
+ ctx->id = atomic_inc_return(&ident);
I suppose we can ignore that this could theoretically wrap around.
Depends on your usecases - if you can envisage a long running client,
say the compositor, while other clients come and go then eventually
these will not be unique and will break the fdinfo spec. Hence I used a
cyclic xarray in i915 (aka idr). I would recommend you just do that and
remove future debug sessions around the area of "why does gputop show
nonsense all of a sudden".
Regards,
Tvrtko
Reviewed-by: Philipp Zabel <p.za...@pengutronix.de>
regards
Philipp
