intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Andi Shyti <andi@etezian.org>
To: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Intel GFX <intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH v4] drm/i915/gt: allow setting generic data pointer
Date: Tue, 10 Mar 2020 00:38:12 +0200	[thread overview]
Message-ID: <20200309223812.GA76960@jack.zhora.eu> (raw)
In-Reply-To: <f1b8da58-e74c-1133-d21a-d22c55bec2ea@intel.com>

Hi Daniele,

> > > > > Quoting Andi Shyti (2020-03-06 23:03:44)
> > > > > > -void debugfs_gt_register_files(struct intel_gt *gt,
> > > > > > -                              struct dentry *root,
> > > > > > -                              const struct debugfs_gt_file *files,
> > > > > > -                              unsigned long count)
> > > > > > +void intel_gt_debugfs_register_files(struct dentry *root,
> > > > > > +                                    const struct debugfs_gt_file *files,
> > > > > > +                                    unsigned long count, void *data)
> > > > > >   {
> > > > > >          while (count--) {
> > > > > > -               if (!files->eval || files->eval(gt))
> > > > > > +               if (!files->eval || files->eval(data))
> > > > > >                          debugfs_create_file(files->name,
> > > > > > -                                           0444, root, gt,
> > > > > > +                                           0444, root, data,
> > > > > >                                              files->fops);
> > > > > 
> > > > > And now we are not a intel_gt routine, you'll want to move again :)
> > > > > i915_debugfs_utils.c ? :)
> > > > 
> > > > Actually, this is what it came to and this was the first
> > > > discussion I had with Daniele and that's also why I was loyal to
> > > > th "_gt_" wrappers until the end. But I had to agree that this
> > > > was becoming more a limitation.
> > > > 
> > > > The biggest difference left, which by the way is the real
> > > > distinguishing factor other than the *gt pointer, is that we
> > > > create files under gt directory, instead of having the root
> > > > imposed by the drm (even though the caller can eventually choose
> > > > different roots).
> > > > 
> > > > We could perhaps store the root pointer in the intel_gt
> > > > structure so that this function stays de facto an intel_gt
> > > > routine and the caller doesn't need to care where the files will
> > > > be generated. This is what we planned to do with sysfs as well.
> > > > 
> > > > What do you think?
> > > 
> > > I thought we were passing along the root. If not I think we should, more
> > > of a debugfs constructor context?
> > 
> > What do you mean with debugfs constructor context? Is it a
> > gt->debugfs_root pointer like the gt->sysfs_root?
> > 

> Getting the root pointer internally from gt wouldn't work well for
> subfolders, like the gt/uc/ folder I want to add for GuC/HuC files.

this was not my idea, actually I was thinking the opposite.

When in this case you call "intel_gt_debugfs_register_files", you
would provide "gt" pointer where the funcion extracts and handles
by its own the debugfs_root. The caller doesn't need to care
about it.

Another idea could be to use contexts, e.g. guc or pm or whatever
comes to mind, and the intel_gt_debugfs handles everything
including subdirectories.

> I think extracting this generic helper to a common file, possibly as a follow-up
> step, isn't a bad idea, also considering that there is at least 1 more
> use-case in i915_debugfs_register(). Maybe we can generalize as something
> like:
> 
> struct i915_debugfs_files {
> 	const char *name;
> 	const struct file_operations *fops;
> 	bool (*eval)(void *data);
> }
> 
> void i915_debugfs_register_files(struct dentry *root,
> 				 const struct i915_debugfs_files *files,
> 				 unsigned long count, void *data)
> {
>  	while (count--) {
> 		umode_t mode = files->fops->write ? 0644 : 0444;
> 		if (!files->eval || files->eval(data))
>  			debugfs_create_file(files->name,
> 					    mode, root, data,
>  					    files->fops);
> 	}
> }

apart from the mode, isn't this the same as the latest patch you
actually reviewed?

> void i915_debugfs_register_files(struct dentry *root,

based on my proposal, root would point, in your case, to the
"guc/" directory that will be created under the "gt/". NULL if
you want the file to be created in the main "gt/" directory.

While if we want to go by context, we could do something like:

struct i915_debugfs_files {                                    
      const char *name;                                        
      const struct file_operations *fops;                      
      bool (*eval)(void *data);                                
      enum intel_gt_context context;
}

and the gt handles everything.

Andi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-03-09 22:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-06 23:03 [Intel-gfx] [PATCH v4] drm/i915/gt: allow setting generic data pointer Andi Shyti
2020-03-07  2:26 ` [Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/gt: allow setting generic data pointer (rev4) Patchwork
2020-03-07  2:40 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-03-07 12:07 ` [Intel-gfx] [PATCH v4] drm/i915/gt: allow setting generic data pointer Chris Wilson
2020-03-07 12:55   ` Andi Shyti
2020-03-07 17:35     ` Chris Wilson
2020-03-07 22:19       ` Andi Shyti
2020-03-09 22:05         ` Daniele Ceraolo Spurio
2020-03-09 22:38           ` Andi Shyti [this message]
2020-03-09 23:11             ` Daniele Ceraolo Spurio
2020-03-11  8:24               ` Andi Shyti
2020-03-12  0:37                 ` Daniele Ceraolo Spurio
2020-03-07 21:10 ` [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: allow setting generic data pointer (rev4) Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200309223812.GA76960@jack.zhora.eu \
    --to=andi@etezian.org \
    --cc=daniele.ceraolospurio@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).