From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: "Lucas De Marchi" <lucas.demarchi@intel.com>,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 3/3] drm/xe/pf: Expose SR-IOV policy settings over debugfs
Date: Mon, 22 Apr 2024 16:28:18 -0400 [thread overview]
Message-ID: <ZibIYmbbPuVSD26a@intel.com> (raw)
In-Reply-To: <3a6d8ca5-eb83-4c62-87cc-80bce1d04a4d@intel.com>
On Mon, Apr 22, 2024 at 10:05:45PM +0200, Michal Wajdeczko wrote:
>
>
> On 22.04.2024 21:39, Rodrigo Vivi wrote:
> > On Thu, Apr 18, 2024 at 10:34:42PM +0200, Michal Wajdeczko wrote:
> >> We already have functions to configure SR-IOV policies.
> >> Allow to tweak those policy settings over debugfs.
> >>
> >> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> >> ---
> >> drivers/gpu/drm/xe/xe_gt_sriov_pf_debugfs.c | 50 +++++++++++++++++++++
> >> 1 file changed, 50 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/xe/xe_gt_sriov_pf_debugfs.c b/drivers/gpu/drm/xe/xe_gt_sriov_pf_debugfs.c
> >> index 8909bb950a8b..3a83af7aa039 100644
> >> --- a/drivers/gpu/drm/xe/xe_gt_sriov_pf_debugfs.c
> >> +++ b/drivers/gpu/drm/xe/xe_gt_sriov_pf_debugfs.c
> >> @@ -17,6 +17,7 @@
> >> #include "xe_gt_sriov_pf_control.h"
> >> #include "xe_gt_sriov_pf_debugfs.h"
> >> #include "xe_gt_sriov_pf_helpers.h"
> >> +#include "xe_gt_sriov_pf_policy.h"
> >> #include "xe_pm.h"
> >>
> >> /*
> >> @@ -76,6 +77,54 @@ static const struct drm_info_list pf_info[] = {
> >> },
> >> };
> >>
> >> +/*
> >> + * /sys/kernel/debug/dri/0/
> >> + * ├── gt0
> >> + * │ ├── pf
> >> + * │ │ ├── reset_engine
> >> + * │ │ ├── sample_period
> >> + * │ │ ├── sched_if_idle
> >> + */
> >> +
> >> +#define DEFINE_SRIOV_GT_POLICY_DEBUGFS_ATTRIBUTE(POLICY, TYPE, FORMAT) \
> >> + \
> >> +static int POLICY##_set(void *data, u64 val) \
> >> +{ \
> >> + struct xe_gt *gt = extract_gt(data); \
> >> + struct xe_device *xe = gt_to_xe(gt); \
> >> + int err; \
> >> + \
> >> + xe_pm_runtime_get(xe); \
> >> + err = xe_gt_sriov_pf_policy_set_##POLICY(gt, val); \
> >> + xe_pm_runtime_put(xe); \
> >
> > I like that this takes care of the runtime_pm in a 'global' way without duplication...
> >
> >> + \
> >> + return err; \
> >> +} \
> >> + \
> >> +static int POLICY##_get(void *data, u64 *val) \
> >> +{ \
> >> + struct xe_gt *gt = extract_gt(data); \
> >> + \
> >> + *val = xe_gt_sriov_pf_policy_get_##POLICY(gt); \
> >> + return 0; \
> >> +} \
> >> + \
> >> +DEFINE_DEBUGFS_ATTRIBUTE(POLICY##_fops, POLICY##_get, POLICY##_set, FORMAT)
> >> +
> >> +DEFINE_SRIOV_GT_POLICY_DEBUGFS_ATTRIBUTE(reset_engine, bool, "%llu\n");
> >> +DEFINE_SRIOV_GT_POLICY_DEBUGFS_ATTRIBUTE(sched_if_idle, bool, "%llu\n");
> >> +DEFINE_SRIOV_GT_POLICY_DEBUGFS_ATTRIBUTE(sample_period, u32, "%llu\n");
> >
> > ... but, is there any other way we could accomplish this without this style
> > that hides function... I hate when I have to understand anything in i915-guc
> > code because you cannot navigate or grep for the functions that are declared
> > with magic macros like this.
>
> but such template macros are quite widely used (at least for sysfs)
>
> $ cgrep ssize_t.*\\#.*show.*\\\\ | wc -l
> 189
>
> and IMO it's better to have one template than replicate very similar
> code N times with just one line difference
>
> besides this are static functions, no need to grep anywhere else
good point indeed. it is not something we will be manually calling from
somewhere else, but never seeing the declaration anywhere like in that
i915 guc code.
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
>
> >
> > but this is my only complain and no big suggestions. I would like to hear
> > from the xe maintainers here.
> >
> > for the debugfs entries and rpm handling and everything I like that.
> >
> >> +
> >> +static void pf_add_policy_attrs(struct xe_gt *gt, struct dentry *parent)
> >> +{
> >> + xe_gt_assert(gt, gt == extract_gt(parent));
> >> + xe_gt_assert(gt, PFID == extract_vfid(parent));
> >> +
> >> + debugfs_create_file_unsafe("reset_engine", 0644, parent, parent, &reset_engine_fops);
> >> + debugfs_create_file_unsafe("sched_if_idle", 0644, parent, parent, &sched_if_idle_fops);
> >> + debugfs_create_file_unsafe("sample_period_ms", 0644, parent, parent, &sample_period_fops);
> >> +}
> >> +
> >> /*
> >> * /sys/kernel/debug/dri/0/
> >> * ├── gt0
> >> @@ -261,6 +310,7 @@ void xe_gt_sriov_pf_debugfs_register(struct xe_gt *gt, struct dentry *root)
> >> pfdentry->d_inode->i_private = gt;
> >>
> >> drm_debugfs_create_files(pf_info, ARRAY_SIZE(pf_info), pfdentry, minor);
> >> + pf_add_policy_attrs(gt, pfdentry);
> >> pf_add_config_attrs(gt, pfdentry, PFID);
> >>
> >> for (n = 1; n <= totalvfs; n++) {
> >> --
> >> 2.43.0
> >>
next prev parent reply other threads:[~2024-04-22 20:28 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-18 20:34 [PATCH 0/3] PF: Expose GT-level SR-IOV details over debugfs Michal Wajdeczko
2024-04-18 20:34 ` [PATCH 1/3] drm/xe/pf: Expose SR-IOV VFs configuration " Michal Wajdeczko
2024-04-22 16:43 ` Piotr Piórkowski
2024-04-22 17:12 ` Michal Wajdeczko
2024-04-18 20:34 ` [PATCH 2/3] drm/xe/pf: Expose SR-IOV VF control commands " Michal Wajdeczko
2024-04-22 16:55 ` Piotr Piórkowski
2024-04-18 20:34 ` [PATCH 3/3] drm/xe/pf: Expose SR-IOV policy settings " Michal Wajdeczko
2024-04-22 17:02 ` Piotr Piórkowski
2024-04-22 17:24 ` Michal Wajdeczko
2024-04-22 19:39 ` Rodrigo Vivi
2024-04-22 20:05 ` Michal Wajdeczko
2024-04-22 20:28 ` Rodrigo Vivi [this message]
2024-04-18 22:24 ` ✓ CI.Patch_applied: success for series starting with [1/3] drm/xe/pf: Expose SR-IOV VFs configuration " Patchwork
2024-04-18 22:24 ` ✗ CI.checkpatch: warning " Patchwork
2024-04-18 22:27 ` ✓ CI.KUnit: success " Patchwork
2024-04-18 22:39 ` ✓ CI.Build: " Patchwork
2024-04-18 22:43 ` ✓ CI.Hooks: " Patchwork
2024-04-18 22:44 ` ✓ CI.checksparse: " Patchwork
2024-04-18 23:40 ` ✓ CI.BAT: " Patchwork
2024-04-20 16:05 ` ✗ CI.FULL: failure " 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=ZibIYmbbPuVSD26a@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=michal.wajdeczko@intel.com \
--cc=thomas.hellstrom@linux.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