From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: "Teres Alexis, Alan Previn" <alan.previn.teres.alexis@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [Intel-gfx 4/6] drm/i915/guc: Provide debugfs for log relay sub-buf info
Date: Tue, 06 Dec 2022 22:00:55 -0800 [thread overview]
Message-ID: <87zgbzda7c.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <b271b532775b9f873ec25c12970bad3dd6392364.camel@intel.com>
On Mon, 05 Dec 2022 17:55:20 -0800, Teres Alexis, Alan Previn wrote:
>
Hi Alan,
> It's been a while - trying to resurrect this now.
>
> On Tue, 2022-07-19 at 20:40 -0700, Dixit, Ashutosh wrote:
> > On Mon, 09 May 2022 14:01:49 -0700, Alan Previn wrote:
> > >
> > >
> Alan: [snip]
>
> > > +#define GUC_LOG_RELAY_SUBBUF_COUNT 8
> > > +u32 intel_guc_log_relay_subbuf_count(struct intel_guc_log *log)
> > > +{
> > > + return GUC_LOG_RELAY_SUBBUF_COUNT;
> > > +}
> >
> > uapi wise, instead of exposing guc_log_size and subbuf_count, why not
> > expose subbuf_size and subbuf_count?
>
> To combine addressing your request + consistency with existing knobs (all
> of which are dedicated for guc-relay-logging), I'll go ahead and change
> it to guc_log_relay_subbuf_size_get and guc_log_relay_subbuf_count_get.
OK, great!
> >
> > > +static int guc_log_relay_buf_size_get(void *data, u64 *val)
> > > +{
> > > + struct intel_guc_log *log = data;
> > > +
> > > + if (!log)
> > > + return -ENODEV;
> > > + if (!log->vma)
> > > + return -ENODEV;
> >
> > Why are these checks needed? Hasn't log been initialized and attached at
> > intel_gt_debugfs_register_files()/debugfs_create_file() time itself?
> >
> > Also if needed let's do:
> >
> > if (!log || !log->vma)
> > return -ENODEV;
> >
> Alan: You are right, we don't to check log but might need to check
> log->vma: its been a long time - i can vaguely remember but i recall some
> weird behavior if the user space was holding on to relay logging handles
> and still calling in while driver is being unloaded. I'll have to retest
> this and see if its something to care about or consider as a user
> error. But even there, we can shorten it to if(!log->vma) as the
> minimum. (of course even if there was a bug, the debugfs path should
> eventually get released as part of the i915 unload but just a tiny bit
> later after the guc resources are freed). Same comment here applies to
> two more comments you provided. Needs to be tested.
So did you test this before sending out the latest series? Or does this
still have to be done? I am holding off on this patch till I hear about
this.
Thanks.
--
Ashutosh
>
> >
> Alan: [snip]
next prev parent reply other threads:[~2022-12-07 6:05 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-09 21:01 [Intel-gfx] [Intel-gfx 0/6] Update GuC relay logging debugfs Alan Previn
2022-05-09 21:01 ` [Intel-gfx] [Intel-gfx 1/6] drm/i915/guc: Fix GuC relay log debugfs failing open Alan Previn
2022-07-19 3:58 ` Dixit, Ashutosh
2022-12-06 8:32 ` Tvrtko Ursulin
2022-12-06 8:35 ` Tvrtko Ursulin
2022-05-09 21:01 ` [Intel-gfx] [Intel-gfx 2/6] drm/i915/guc: Add unaligned wc memcpy for copying GuC Log Alan Previn
2022-07-19 17:54 ` Dixit, Ashutosh
2022-05-09 21:01 ` [Intel-gfx] [Intel-gfx 3/6] drm/i915/guc: Add a helper for log buffer size Alan Previn
2022-07-20 2:49 ` Dixit, Ashutosh
2022-12-06 1:56 ` Teres Alexis, Alan Previn
2022-05-09 21:01 ` [Intel-gfx] [Intel-gfx 4/6] drm/i915/guc: Provide debugfs for log relay sub-buf info Alan Previn
2022-07-20 3:40 ` Dixit, Ashutosh
2022-12-06 1:55 ` Teres Alexis, Alan Previn
2022-12-07 6:00 ` Dixit, Ashutosh [this message]
2022-05-09 21:01 ` [Intel-gfx] [Intel-gfx 5/6] drm/i915/guc: Rename GuC log relay debugfs descriptively Alan Previn
2022-07-20 5:39 ` Dixit, Ashutosh
2022-12-06 1:58 ` Teres Alexis, Alan Previn
2022-05-09 21:01 ` [Intel-gfx] [Intel-gfx 6/6] drm/i915/guc: Move guc_log_relay_chan debugfs path to uc Alan Previn
2022-07-20 19:08 ` Dixit, Ashutosh
2022-12-06 2:01 ` Teres Alexis, Alan Previn
2022-12-06 6:08 ` Teres Alexis, Alan Previn
2022-05-09 21:25 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Update GuC relay logging debugfs Patchwork
2022-05-09 21:41 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-05-10 10:00 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-05-11 21:45 ` Teres Alexis, Alan Previn
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=87zgbzda7c.wl-ashutosh.dixit@intel.com \
--to=ashutosh.dixit@intel.com \
--cc=alan.previn.teres.alexis@intel.com \
--cc=intel-gfx@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