Hi Daniel, On Thu, 5 Jan 2023 16:31:49 +0100 Daniel Vetter <daniel@xxxxxxxx> wrote: > On Wed, Jan 04, 2023 at 02:03:05PM +0100, Boris Brezillon wrote: > > Provide a dummy show_fdinfo() implementation exposing drm-driver and > > drm-client-id. More stats will be added soon. > > > > Signed-off-by: Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx> > > --- > > drivers/gpu/drm/panfrost/panfrost_drv.c | 17 ++++++++++++++++- > > 1 file changed, 16 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c > > index 2fa5afe21288..6ee43559fc14 100644 > > --- a/drivers/gpu/drm/panfrost/panfrost_drv.c > > +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c > > @@ -515,7 +515,22 @@ static const struct drm_ioctl_desc panfrost_drm_driver_ioctls[] = { > > PANFROST_IOCTL(MADVISE, madvise, DRM_RENDER_ALLOW), > > }; > > > > -DEFINE_DRM_GEM_FOPS(panfrost_drm_driver_fops); > > +static void panfrost_show_fdinfo(struct seq_file *m, struct file *f) > > +{ > > + struct drm_file *file = f->private_data; > > + struct panfrost_file_priv *panfrost_priv = file->driver_priv; > > + > > + seq_printf(m, "drm-driver:\t%s\n", file->minor->dev->driver->name); > > + seq_printf(m, "drm-client-id:\t%llu\n", panfrost_priv->sched_entity[0].fence_context); > > I think at this point we really need to not just have a document that says > what this should look like, but drm infrastructure with shared code. > Drivers all inventing their fdinfo really doesn't seem like a great idea > to me. Okay. I'm just curious how far you want to go with this common infrastructure? Are we talking about having a generic helper printing the pretty generic drm-{driver,client-id} props and letting the driver prints its driver specific properties, or do you also want to standardize/automate printing of some drm-memory/drm-engine props too? Regards, Boris