From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Andi Shyti <andi.shyti@linux.intel.com>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
Tvrtko Ursulin <tursulin@ursulin.net>,
Chris Wilson <chris.p.wilson@linux.intel.com>
Subject: Re: [PATCH] drm/i915/gt: Continue creating engine sysfs files even after a failure
Date: Tue, 27 Aug 2024 19:05:05 +0200 [thread overview]
Message-ID: <Zs4HQR-gcZ_VHMMF@phenom.ffwll.local> (raw)
In-Reply-To: <20240819113140.325235-1-andi.shyti@linux.intel.com>
On Mon, Aug 19, 2024 at 01:31:40PM +0200, Andi Shyti wrote:
> The i915 driver generates sysfs entries for each engine of the
> GPU in /sys/class/drm/cardX/engines/.
>
> The process is straightforward: we loop over the UABI engines and
> for each one, we:
>
> - Create the object.
> - Create basic files.
> - If the engine supports timeslicing, create timeslice duration files.
> - If the engine supports preemption, create preemption-related files.
> - Create default value files.
>
> Currently, if any of these steps fail, the process stops, and no
> further sysfs files are created.
>
> However, it's not necessary to stop the process on failure.
> Instead, we can continue creating the remaining sysfs files for
> the other engines. Even if some files fail to be created, the
> list of engines can still be retrieved by querying i915.
>
> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Uh, sysfs is uapi. Either we need it, and it _must_ be there, or it's not
needed, and we should delete those files probably.
This is different from debugfs, where failures are consistently ignored
because that's the conscious design choice Greg made and wants supported.
Because debugfs is optional.
So please make sure we correctly fail driver load if these don't register.
Even better would be if sysfs files are registered atomically as attribute
blocks, but that's an entire different can of worms. But that would really
clean up this code and essentially put any failure handling onto core
driver model and sysfs code.
-Sima
> ---
> Hi,
>
> It might make sense to create an "inv-<engine_name>" if something
> goes wrong, so that the user is aware that the engine exists, but
> the sysfs file is not present.
>
> One further improvement would be to provide more information
> about thei failure reason the dev_warn() message.
>
> Andi
>
> drivers/gpu/drm/i915/gt/sysfs_engines.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/sysfs_engines.c b/drivers/gpu/drm/i915/gt/sysfs_engines.c
> index 021f51d9b456..aab2759067d2 100644
> --- a/drivers/gpu/drm/i915/gt/sysfs_engines.c
> +++ b/drivers/gpu/drm/i915/gt/sysfs_engines.c
> @@ -530,9 +530,8 @@ void intel_engines_add_sysfs(struct drm_i915_private *i915)
> err_object:
> kobject_put(kobj);
> err_engine:
> - dev_err(kdev, "Failed to add sysfs engine '%s'\n",
> - engine->name);
> - break;
> + dev_warn(kdev, "Failed to add sysfs engine '%s'\n",
> + engine->name);
> }
> }
> }
> --
> 2.45.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2024-08-27 17:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-19 11:31 [PATCH] drm/i915/gt: Continue creating engine sysfs files even after a failure Andi Shyti
2024-08-19 12:06 ` ✓ Fi.CI.BAT: success for " Patchwork
2024-08-20 6:58 ` ✗ Fi.CI.IGT: failure " Patchwork
2024-08-20 21:22 ` [PATCH] " Rodrigo Vivi
2024-08-21 7:32 ` Andi Shyti
2024-08-21 10:34 ` Andi Shyti
2024-08-23 13:41 ` Rodrigo Vivi
2024-08-23 22:26 ` Andi Shyti
2024-08-27 17:05 ` Daniel Vetter [this message]
2024-08-28 20:17 ` Rodrigo Vivi
2024-09-04 13:20 ` Andi Shyti
2024-09-04 14:34 ` Jani Nikula
2024-09-04 15:08 ` Tvrtko Ursulin
2024-09-04 15:13 ` Rodrigo Vivi
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=Zs4HQR-gcZ_VHMMF@phenom.ffwll.local \
--to=daniel.vetter@ffwll.ch \
--cc=andi.shyti@linux.intel.com \
--cc=chris.p.wilson@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=tursulin@ursulin.net \
/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