From: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
To: Andi Shyti <andi.shyti@linux.intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [Intel-xe] [PATCH v2 2/3] drm/xe: Allow userspace to configure CCS mode
Date: Fri, 1 Dec 2023 21:48:23 -0800 [thread overview]
Message-ID: <ZWrFJ94oDqiIN9pt@nvishwa1-DESK> (raw)
In-Reply-To: <ZWpIzR3ucjwkNRty@ashyti-mobl2.lan>
On Fri, Dec 01, 2023 at 09:57:49PM +0100, Andi Shyti wrote:
>Hi Niranjana,
>
>> +static ssize_t
>> +ccs_mode_show(struct device *kdev,
>> + struct device_attribute *attr, char *buf)
>> +{
>> + struct xe_gt *gt = kobj_to_gt(&kdev->kobj);
>> +
>> + return sysfs_emit(buf, "Enabled compute engines %d; Number of compute slices %d\n",
>> + gt->ccs_mode.num_engines, hweight32(CCS_MASK(gt)));
>> +}
>
>Please add separate interfaces called:
>
> - compute_engines
> - compute_slices
>
>and each of them providing respecively
>
> - gt->ccs_mode.num_engines
> - hweight32(CCS_MASK(gt))
>
Thanks Andi for the review.
Yah, I like that idea.
I will make it,
- ccs_mode, a RW interface for reading/configuring ccs_mode(num_engines)
- compute_slices, a read-only interface for reading number of available compute slices.
>> +static ssize_t
>> +ccs_mode_store(struct device *kdev, struct device_attribute *attr,
>> + const char *buff, size_t count)
>> +{
>> + struct xe_gt *gt = kobj_to_gt(&kdev->kobj);
>> + u32 num_engines, num_slices;
>> + int ret;
>> +
>> + ret = kstrtou32(buff, 0, &num_engines);
>> + if (ret)
>> + return ret;
>> +
>> + /*
>> + * Ensure number of engines specified is valid and there is an
>> + * exact multiple of engines for slices.
>> + */
>> + num_slices = hweight32(CCS_MASK(gt));
>> + if (!num_engines || num_engines > num_slices || num_slices % num_engines) {
>> + xe_gt_dbg(gt, "Invalid compute config, %d engines %d slices\n",
>> + num_engines, num_slices);
>> + return -EINVAL;
>> + }
>> +
>> + if (gt->ccs_mode.num_engines != num_engines) {
>> + xe_gt_info(gt, "Setting compute mode to %d\n", num_engines);
>> + gt->ccs_mode.num_engines = num_engines;
>> + xe_gt_reset_async(gt);
>> + }
>> +
>> + return count;
>> +}
>> +
>> +static DEVICE_ATTR_RW(ccs_mode);
>> +
>> +static void xe_gt_ccs_mode_sysfs_fini(struct drm_device *drm, void *arg)
>> +{
>> + struct xe_gt *gt = arg;
>> +
>> + sysfs_remove_file(gt->sysfs, &dev_attr_ccs_mode.attr);
>> +}
>
>I think there's no need to remove sysfs files.
>
I see all instances of sysfs_create_file/s have a corresponding
sysfs_remove_file/s, except in xe_tile_sysfs.c case.
So, I think it is better to keep it.
>> +int xe_gt_ccs_mode_sysfs_init(struct xe_gt *gt)
>> +{
>> + struct xe_device *xe = gt_to_xe(gt);
>> + int err;
>> +
>> + if (!xe_gt_ccs_mode_enabled(gt))
>> + return 0;
>> +
>> + err = sysfs_create_file(gt->sysfs, &dev_attr_ccs_mode.attr);
>> + if (err)
>> + return err;
>> +
>> + err = drmm_add_action_or_reset(&xe->drm, xe_gt_ccs_mode_sysfs_fini, gt);
>> + if (err)
>> + drm_warn(&xe->drm, "%s: drmm_add_action_or_reset failed, err: %d\n",
>> + __func__, err);
>> +
>> + return err;
>
>Please, don't fail if sysfs fails. Make this function void.
>
The caller of this function is just printing a message upon error.
I guess we can just add the message here if sysfs_create_file fails and
make this function return type void. Will change.
Niranjana
>Andi
next prev parent reply other threads:[~2023-12-02 5:48 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-29 2:57 [Intel-xe] [PATCH v2 0/3] drm/xe: Enable fixed CCS mode Niranjana Vishwanathapura
2023-11-29 2:57 ` [Intel-xe] [PATCH v2 1/3] drm/xe: Enable Fixed CCS mode setting Niranjana Vishwanathapura
2023-12-01 20:52 ` Andi Shyti
2023-12-02 6:05 ` Niranjana Vishwanathapura
2023-11-29 2:57 ` [Intel-xe] [PATCH v2 2/3] drm/xe: Allow userspace to configure CCS mode Niranjana Vishwanathapura
2023-12-01 20:57 ` Andi Shyti
2023-12-02 5:48 ` Niranjana Vishwanathapura [this message]
2023-11-29 2:57 ` [Intel-xe] [PATCH v2 3/3] drm/xe: Avoid any races around ccs_mode update Niranjana Vishwanathapura
2023-12-01 20:59 ` Andi Shyti
2023-12-02 2:37 ` Niranjana Vishwanathapura
2024-09-04 10:28 ` Simona Vetter
2023-11-29 4:50 ` [Intel-xe] ✓ CI.Patch_applied: success for drm/xe: Enable fixed CCS mode Patchwork
2023-11-29 4:51 ` [Intel-xe] ✗ CI.checkpatch: warning " Patchwork
2023-11-29 4:52 ` [Intel-xe] ✓ CI.KUnit: success " Patchwork
2023-11-29 4:59 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-11-29 4:59 ` [Intel-xe] ✓ CI.Hooks: " Patchwork
2023-11-29 5:01 ` [Intel-xe] ✓ CI.checksparse: " Patchwork
2023-11-29 5:34 ` [Intel-xe] ✓ CI.BAT: " 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=ZWrFJ94oDqiIN9pt@nvishwa1-DESK \
--to=niranjana.vishwanathapura@intel.com \
--cc=andi.shyti@linux.intel.com \
--cc=intel-xe@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