From: Matt Roper <matthew.d.roper@intel.com>
To: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH dii-client 6/9] drm/i915/debugfs: Multiplex upper layer interfaces to act on all gt's
Date: Thu, 19 Jan 2023 17:25:29 -0800 [thread overview]
Message-ID: <Y8ntids89iu4soYr@mdroper-desk1.amr.corp.intel.com> (raw)
In-Reply-To: <20230111235531.3353815-7-radhakrishna.sripada@intel.com>
On Wed, Jan 11, 2023 at 03:55:28PM -0800, Radhakrishna Sripada wrote:
> From: Andi Shyti <andi.shyti@linux.intel.com>
>
> Commit 82a149a62b6b5 ('drm/i915/gt: move remaining debugfs
> interfaces into gt') moves gt related debugfs files in the gtX/
> directories to act on specific gt's individually.
There's another thread somewhere on the list where these top-level
entries are being discussed (maybe that one is sysfs rather than
debugfs, but the idea is the same). Having entries in the per-gt
directories and another copy outside the GT hierarchy is just confusing
since the semantics aren't clear. It would be better if we just clean
up the interface and stop exposing those top-level nodes on any platform
that's still under force_probe protection.
>
> The original files are kept intact in the same location in order
> to not break userspace users. But they were performing only on
> the root tile (tile 0).
When starting to work on a new platform we have the opportunity to
change API's (even stuff that's ABI) and sunset legacy interfaces that
no longer make sense as long as the platform isn't fully enabled with
force_probe protection lifted. There's no requirement that userspace
for platform n-1 must work without any changes on platform n. That's
especially true for debugfs which isn't even considered ABI.
>
> Add a multiplexing functionality to the higher directories files
> so that they can perform the operations on all the tiles in a
> with a single write.
This sounds unnecessary.
>
> In the read case they provide an or'ed value amongst the tiles.
And this sounds like it could be harmful on a platform like MTL with
heterogeneous GTs that are responsible for very different things. And
if some debugfs interfaces return information other than booleans, using
different semantics to combine the information from multiple GTs could
lead to even more confusion and problems. I think it's much better to
keep things simple, eliminate the ambiguous entries that are outside the
gt directories, and keep things simple.
Matt
>
> Cc: Maciej Patelczyk <maciej.patelczyk@intel.com>
> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 38 ++++++++++++++++++++++++++---
> 1 file changed, 34 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
> index a356ca490159..d64e9e3a439d 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -575,14 +575,36 @@ static int i915_wa_registers(struct seq_file *m, void *unused)
> static int i915_wedged_get(void *data, u64 *val)
> {
> struct drm_i915_private *i915 = data;
> + struct intel_gt *gt;
> + unsigned int i;
>
> - return intel_gt_debugfs_reset_show(to_gt(i915), val);
> + *val = 0;
> +
> + for_each_gt(gt, i915, i) {
> + int ret;
> + u64 v;
> +
> + ret = intel_gt_debugfs_reset_show(gt, &v);
> + if (ret)
> + return ret;
> +
> + /* at least one tile should be wedged */
> + *val |= !!v;
> + if (*val)
> + break;
> + }
> +
> + return 0;
> }
>
> static int i915_wedged_set(void *data, u64 val)
> {
> struct drm_i915_private *i915 = data;
> - intel_gt_debugfs_reset_store(to_gt(i915), val);
> + struct intel_gt *gt;
> + unsigned int i;
> +
> + for_each_gt(gt, i915, i)
> + intel_gt_debugfs_reset_store(gt, val);
>
> return 0;
> }
> @@ -732,7 +754,11 @@ static int i915_sseu_status(struct seq_file *m, void *unused)
> static int i915_forcewake_open(struct inode *inode, struct file *file)
> {
> struct drm_i915_private *i915 = inode->i_private;
> - intel_gt_pm_debugfs_forcewake_user_open(to_gt(i915));
> + struct intel_gt *gt;
> + unsigned int i;
> +
> + for_each_gt(gt, i915, i)
> + intel_gt_pm_debugfs_forcewake_user_open(gt);
>
> return 0;
> }
> @@ -740,7 +766,11 @@ static int i915_forcewake_open(struct inode *inode, struct file *file)
> static int i915_forcewake_release(struct inode *inode, struct file *file)
> {
> struct drm_i915_private *i915 = inode->i_private;
> - intel_gt_pm_debugfs_forcewake_user_release(to_gt(i915));
> + struct intel_gt *gt;
> + unsigned int i;
> +
> + for_each_gt(gt, i915, i)
> + intel_gt_pm_debugfs_forcewake_user_release(gt);
>
> return 0;
> }
> --
> 2.34.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
next prev parent reply other threads:[~2023-01-20 1:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-11 23:55 [Intel-gfx] [PATCH dii-client 0/9] Misc Meteorlake patches Radhakrishna Sripada
2023-01-11 23:55 ` [Intel-gfx] [PATCH dii-client 1/9] drm/i915/mtl: Fix bcs default context Radhakrishna Sripada
2023-01-12 0:13 ` Matt Roper
2023-01-11 23:55 ` [Intel-gfx] [PATCH dii-client 2/9] drm/i915/mtl: Initialize empty clockgating hooks for MTL Radhakrishna Sripada
2023-01-20 0:45 ` Matt Roper
2023-01-11 23:55 ` [Intel-gfx] [PATCH dii-client 3/9] drm/i915/mtl: Fix Wa_14015855405 implementation Radhakrishna Sripada
2023-01-23 11:03 ` Balasubramani Vivekanandan
2023-01-11 23:55 ` [Intel-gfx] [PATCH dii-client 4/9] drm/i915/mtl: make IRQ reset and postinstall multi-gt aware Radhakrishna Sripada
2023-01-20 1:11 ` Matt Roper
2023-01-11 23:55 ` [Intel-gfx] [PATCH dii-client 5/9] drm/i915/gt: generate per gt debugfs files Radhakrishna Sripada
2023-01-25 11:42 ` Balasubramani Vivekanandan
2023-01-11 23:55 ` [Intel-gfx] [PATCH dii-client 6/9] drm/i915/debugfs: Multiplex upper layer interfaces to act on all gt's Radhakrishna Sripada
2023-01-20 1:25 ` Matt Roper [this message]
2023-01-11 23:55 ` [Intel-gfx] [PATCH dii-client 7/9] drm/i915/fbdev: lock the fbdev obj before vma pin Radhakrishna Sripada
2023-01-11 23:55 ` [Intel-gfx] [PATCH dii-client 8/9] drm/i915/mtl: Skip pcode qgv restrictions for MTL Radhakrishna Sripada
2023-01-20 1:32 ` Matt Roper
2023-01-11 23:55 ` [Intel-gfx] [PATCH dii-client 9/9] drm/i915/display/mtl: Program latch to phy reset Radhakrishna Sripada
2023-01-12 0:38 ` [Intel-gfx] ✓ Fi.CI.BAT: success for Misc Meteorlake patches Patchwork
2023-01-12 3:44 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=Y8ntids89iu4soYr@mdroper-desk1.amr.corp.intel.com \
--to=matthew.d.roper@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=radhakrishna.sripada@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