On Mon, 9 Jan 2023 at 09:34, Boris Brezillon
<boris.brezillon@xxxxxxxxxxxxx> wrote:
>
> 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?
I think we should standardized what's used by multiple drivers at
least. It might be a bit tough for the memory/engine props, because
there's really not much standard stuff there yet (e.g. for memory I'm
still hoping for cgroups work, for engines we should probably base
this on drm_sched_entity and maybe untie that somewhat from sched
itself for i915-sched and fw sched and whatever there is).
But as usual, try to be reasonable with standard code :-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
