All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ghimiray, Himal Prasad" <himal.prasad.ghimiray@intel.com>
To: Tejas Upadhyay <tejas.upadhyay@intel.com>,
	<intel-xe@lists.freedesktop.org>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [PATCH] drm/xe: sysfs_ops needs to be defined on parent directory
Date: Tue, 25 Mar 2025 15:18:40 +0530	[thread overview]
Message-ID: <e91f93d2-a4e2-4304-b026-eea2f1fae13d@intel.com> (raw)
In-Reply-To: <20250319121349.288844-1-tejas.upadhyay@intel.com>



On 19-03-2025 17:43, Tejas Upadhyay wrote:
> Currently, xe_hw_engine_sysfs_kobj_type is defining sysfs_ops
> on wrong directory. Sysfs_ops needs to be defined on immediate
> parent directory to be able to called on each attribute set/get.
> 
> Fixes: 3f0e14651ab0 ("drm/xe: Runtime PM wake on every sysfs call")
> Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
> ---
>   drivers/gpu/drm/xe/xe_hw_engine_class_sysfs.c | 67 +++++++++----------
>   1 file changed, 33 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_hw_engine_class_sysfs.c b/drivers/gpu/drm/xe/xe_hw_engine_class_sysfs.c
> index b53e8d2accdb..25592f178482 100644
> --- a/drivers/gpu/drm/xe/xe_hw_engine_class_sysfs.c
> +++ b/drivers/gpu/drm/xe/xe_hw_engine_class_sysfs.c
> @@ -492,39 +492,6 @@ static const struct attribute * const files[] = {
>   	NULL
>   };
>   
> -static void kobj_xe_hw_engine_class_fini(void *arg)
> -{
> -	struct kobject *kobj = arg;
> -
> -	sysfs_remove_files(kobj, files);
> -	kobject_put(kobj);
> -}
> -
> -static struct kobj_eclass *
> -kobj_xe_hw_engine_class(struct xe_device *xe, struct kobject *parent, const char *name)
> -{
> -	struct kobj_eclass *keclass;
> -	int err = 0;
> -
> -	keclass = kzalloc(sizeof(*keclass), GFP_KERNEL);
> -	if (!keclass)
> -		return NULL;
> -
> -	kobject_init(&keclass->base, &kobj_xe_hw_engine_type);
> -	if (kobject_add(&keclass->base, parent, "%s", name)) {
> -		kobject_put(&keclass->base);
> -		return NULL;
> -	}
> -	keclass->xe = xe;
> -
> -	err = devm_add_action_or_reset(xe->drm.dev, kobj_xe_hw_engine_class_fini,
> -				       &keclass->base);
> -	if (err)
> -		return NULL;
> -
> -	return keclass;
> -}
> -
>   static void hw_engine_class_defaults_fini(void *arg)
>   {
>   	struct kobject *kobj = arg;
> @@ -611,6 +578,38 @@ static const struct kobj_type xe_hw_engine_sysfs_kobj_type = {
>   	.sysfs_ops = &xe_hw_engine_class_sysfs_ops,
>   };
>   
> +static void kobj_xe_hw_engine_class_fini(void *arg)
> +{
> +	struct kobject *kobj = arg;
> +
> +	sysfs_remove_files(kobj, files);
> +	kobject_put(kobj);
> +}
> +
> +static struct kobj_eclass *
> +kobj_xe_hw_engine_class(struct xe_device *xe, struct kobject *parent, const char *name)
> +{
> +	struct kobj_eclass *keclass;
> +	int err = 0;
> +
> +	keclass = kzalloc(sizeof(*keclass), GFP_KERNEL);
> +	if (!keclass)
> +		return NULL;
> +
> +	kobject_init(&keclass->base, &xe_hw_engine_sysfs_kobj_type);
> +	if (kobject_add(&keclass->base, parent, "%s", name)) {
> +		kobject_put(&keclass->base);
> +		return NULL;
> +	}
> +	keclass->xe = xe;
> +
> +	err = devm_add_action_or_reset(xe->drm.dev, kobj_xe_hw_engine_class_fini,
> +				       &keclass->base);
> +	if (err)
> +		return NULL;
> +
> +	return keclass;
> +}
>   static void hw_engine_class_sysfs_fini(void *arg)
>   {
>   	struct kobject *kobj = arg;
> @@ -640,7 +639,7 @@ int xe_hw_engine_class_sysfs_init(struct xe_gt *gt)
>   	if (!kobj)
>   		return -ENOMEM;
>   
> -	kobject_init(kobj, &xe_hw_engine_sysfs_kobj_type);
> +	kobject_init(kobj, &kobj_xe_hw_engine_type);


The patch makes sense if we need to use xe_pm_runtime_get and 
xe_pm_runtime_put to show and store the attributes. Are there any 
hardware read/writes associated with these attribute store/show 
operations? If not, why do we need pm_runtime just for software states?

+Rodrigo, for his views here.

>   
>   	err = kobject_add(kobj, gt->sysfs, "engines");
>   	if (err)


  parent reply	other threads:[~2025-03-25  9:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-19 12:13 [PATCH] drm/xe: sysfs_ops needs to be defined on parent directory Tejas Upadhyay
2025-03-19 12:22 ` ✓ CI.Patch_applied: success for " Patchwork
2025-03-19 12:23 ` ✓ CI.checkpatch: " Patchwork
2025-03-19 12:24 ` ✓ CI.KUnit: " Patchwork
2025-03-19 12:40 ` ✓ CI.Build: " Patchwork
2025-03-19 12:43 ` ✓ CI.Hooks: " Patchwork
2025-03-19 12:44 ` ✓ CI.checksparse: " Patchwork
2025-03-19 13:03 ` ✓ Xe.CI.BAT: " Patchwork
2025-03-19 14:05 ` ✓ Xe.CI.Full: " Patchwork
2025-03-25  9:48 ` Ghimiray, Himal Prasad [this message]
2025-03-25 19:14   ` [PATCH] " Rodrigo Vivi
2025-03-25 19:12 ` Rodrigo Vivi
2025-03-26  4:14   ` Upadhyay, Tejas
2025-03-26 14:43     ` Rodrigo Vivi
2025-03-26 14:50       ` Upadhyay, Tejas

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=e91f93d2-a4e2-4304-b026-eea2f1fae13d@intel.com \
    --to=himal.prasad.ghimiray@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=tejas.upadhyay@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.