Hi Daniel,

On Thu, 5 Jan 2023 16:31:49 +0100
Daniel Vetter <dan...@ffwll.ch> 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.brezil...@collabora.com>
> > ---
> >  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

Reply via email to