public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Andi Shyti <andi.shyti@linux.intel.com>
To: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Intel GFX <intel-gfx@lists.freedesktop.org>,
	Lucas De Marchi <lucas.demarchi@intel.com>,
	DRI Devel <dri-devel@lists.freedesktop.org>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	Matthew Auld <matthew.auld@intel.com>
Subject: Re: [Intel-gfx] [PATCH v5 4/7] drm/i915/gt: create per-tile sysfs interface
Date: Mon, 7 Mar 2022 01:04:26 +0200	[thread overview]
Message-ID: <YiU9+uRCzJAZlcRh@intel.intel> (raw)
In-Reply-To: <e096ed88-ec87-b45c-22ba-80d48f480808@intel.com>

Hi Andrzej,

[...]

> > +bool is_object_gt(struct kobject *kobj)
> > +{
> > +	return !strncmp(kobj->name, "gt", 2);
> > +}
> 
> It looks quite fragile, at the moment I do not have better idea:) maybe
> after reviewing the rest of the patches.

yeah... it's not pretty, I agree, but I couldn't come up with a
better way of doing it.

> > +static struct intel_gt *kobj_to_gt(struct kobject *kobj)
> > +{
> > +	return container_of(kobj, struct kobj_gt, base)->gt;
> > +}
> > +
> > +struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
> > +					    const char *name)
> > +{
> > +	struct kobject *kobj = &dev->kobj;
> > +
> > +	/*
> > +	 * We are interested at knowing from where the interface
> > +	 * has been called, whether it's called from gt/ or from
> > +	 * the parent directory.
> > +	 * From the interface position it depends also the value of
> > +	 * the private data.
> > +	 * If the interface is called from gt/ then private data is
> > +	 * of the "struct intel_gt *" type, otherwise it's * a
> > +	 * "struct drm_i915_private *" type.
> > +	 */
> > +	if (!is_object_gt(kobj)) {
> > +		struct drm_i915_private *i915 = kdev_minor_to_i915(dev);
> > +
> > +		pr_devel_ratelimited(DEPRECATED
> > +			"%s (pid %d) is accessing deprecated %s "
> > +			"sysfs control, please use gt/gt<n>/%s instead\n",
> > +			current->comm, task_pid_nr(current), name, name);
> > +		return to_gt(i915);
> > +	}
> > +
> > +	return kobj_to_gt(kobj);
> 
> It took some time for me to understand what is going on here.
> We have dev argument which sometimes can point to "struct device", sometimes
> to "struct kobj_gt", but it's type suggests differently, quite ugly.
> I wonder if wouldn't be better to use __ATTR instead of DEVICE_ATTR* as in
> case of intel_engines_add_sysfs. This way abstractions would look better,
> hopefully.

How would it help?

The difference is that I'm adding twice different interfaces with
the same name and different location (i.e. different object). The
legacy intrefaces inherit the object from drm and I'm preserving
that reference.

While the new objects would derive from the previous and they are
pretty much like intel_engines_add_sysfs().

[...]

> > +struct kobject *
> > +intel_gt_create_kobj(struct intel_gt *gt, struct kobject *dir, const char *name)
> > +{
> > +	struct kobj_gt *kg;
> > +
> > +	kg = kzalloc(sizeof(*kg), GFP_KERNEL);
> > +	if (!kg)
> > +		return NULL;
> > +
> > +	kobject_init(&kg->base, &kobj_gt_type);
> > +	kg->gt = gt;
> > +
> > +	/* xfer ownership to sysfs tree */
> > +	if (kobject_add(&kg->base, dir, "%s", name)) {
> > +		kobject_put(&kg->base);
> > +		return NULL;
> > +	}
> > +
> > +	return &kg->base; /* borrowed ref */
> > +}
> > +
> > +void intel_gt_sysfs_register(struct intel_gt *gt)
> > +{
> > +	struct kobject *dir;
> > +	char name[80];
> > +
> > +	snprintf(name, sizeof(name), "gt%d", gt->info.id);
> > +
> > +	dir = intel_gt_create_kobj(gt, gt->i915->sysfs_gt, name);
> > +	if (!dir) {
> > +		drm_warn(&gt->i915->drm,
> > +			 "failed to initialize %s sysfs root\n", name);
> > +		return;
> > +	}
> > +}
> 
> Squashing intel_gt_create_kobj into intel_gt_sysfs_register would simplify
> code and allows drop snprintf to local array.

right!

> > +static struct kobject *i915_setup_gt_sysfs(struct kobject *parent)
> > +{
> > +	return kobject_create_and_add("gt", parent);
> > +}
> > +
> >   void i915_setup_sysfs(struct drm_i915_private *dev_priv)
> >   {
> >   	struct device *kdev = dev_priv->drm.primary->kdev;
> > @@ -538,6 +543,11 @@ void i915_setup_sysfs(struct drm_i915_private *dev_priv)
> >   	if (ret)
> >   		drm_err(&dev_priv->drm, "RPS sysfs setup failed\n");
> > +	dev_priv->sysfs_gt = i915_setup_gt_sysfs(&kdev->kobj);
> 
> Why not directly kobject_create_and_add("gt", parent) ? up to you.

of course!

[...]

Thanks a lot for the review,
Andi

  reply	other threads:[~2022-03-06 23:04 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-17 14:41 [Intel-gfx] [PATCH v5 0/7] Introduce multitile support Andi Shyti
2022-02-17 14:41 ` [Intel-gfx] [PATCH v5 1/7] drm/i915: Rename INTEL_REGION_LMEM with INTEL_REGION_LMEM_0 Andi Shyti
2022-02-28 19:53   ` Michal Wajdeczko
2022-03-01 15:19   ` Andrzej Hajda
2022-02-17 14:41 ` [Intel-gfx] [PATCH v5 2/7] drm/i915: Prepare for multiple GTs Andi Shyti
2022-03-01 15:15   ` Andrzej Hajda
2022-03-06 19:20     ` Andi Shyti
2022-02-17 14:41 ` [Intel-gfx] [PATCH v5 3/7] drm/i915/gt: add gt_is_root() helper Andi Shyti
2022-02-28 20:02   ` Michal Wajdeczko
2022-03-01 15:25     ` Andrzej Hajda
2022-03-06 19:23       ` Andi Shyti
2022-02-17 14:41 ` [Intel-gfx] [PATCH v5 4/7] drm/i915/gt: create per-tile sysfs interface Andi Shyti
2022-03-02 16:57   ` Andrzej Hajda
2022-03-06 23:04     ` Andi Shyti [this message]
2022-03-07 20:25       ` Andrzej Hajda
2022-03-13 19:45         ` Andi Shyti
2022-03-13 21:30           ` Andi Shyti
2022-03-14 12:08           ` Andrzej Hajda
2022-02-17 14:41 ` [Intel-gfx] [PATCH v5 5/7] drm/i915/gt: Create per-tile RC6 " Andi Shyti
2022-02-17 15:34   ` Tvrtko Ursulin
2022-02-17 15:53     ` Andi Shyti
2022-02-18  9:12       ` Tvrtko Ursulin
2022-02-18  9:21         ` Andi Shyti
2022-02-18 10:46       ` Joonas Lahtinen
2022-02-21 17:12         ` Tvrtko Ursulin
2022-02-22  8:57           ` Andi Shyti
2022-11-07  0:08             ` Dixit, Ashutosh
2022-02-17 20:49   ` kernel test robot
2022-02-17 23:53   ` kernel test robot
2022-03-03 10:19   ` Andrzej Hajda
2022-03-13 22:15     ` Andi Shyti
2022-02-17 14:41 ` [Intel-gfx] [PATCH v5 6/7] drm/i915/gt: Create per-tile RPS sysfs interfaces Andi Shyti
2022-02-17 19:47   ` kernel test robot
2022-03-03 10:55   ` Andrzej Hajda
2022-03-13 23:09     ` Andi Shyti
2022-02-17 14:41 ` [Intel-gfx] [PATCH v5 7/7] drm/i915/gt: Adding new sysfs frequency attributes Andi Shyti
2022-02-17 15:45   ` Andi Shyti
2022-02-17 17:06     ` Sundaresan, Sujaritha
2022-02-28 20:37   ` Michal Wajdeczko
2022-03-14  0:38     ` Andi Shyti
2022-03-14  1:32       ` Sundaresan, Sujaritha
2022-03-03 11:17   ` Andrzej Hajda
2022-02-17 23:12 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Introduce multitile support Patchwork
2022-02-17 23:13 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-02-17 23:40 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-02-17 23:40 ` [Intel-gfx] ✗ Fi.CI.BUILD: warning " 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=YiU9+uRCzJAZlcRh@intel.intel \
    --to=andi.shyti@linux.intel.com \
    --cc=andrzej.hajda@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.auld@intel.com \
    /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