From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: akash.goel@intel.com, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 20/20] drm/i915: Early creation of relay channel for capturing boot time logs
Date: Fri, 12 Aug 2016 17:22:07 +0100 [thread overview]
Message-ID: <57ADF7AF.5000803@linux.intel.com> (raw)
In-Reply-To: <1470983123-22127-21-git-send-email-akash.goel@intel.com>
On 12/08/16 07:25, akash.goel@intel.com wrote:
> From: Akash Goel <akash.goel@intel.com>
>
> As per the current i915 Driver load sequence, debugfs registration is done
> at the end and so the relay channel debugfs file is also created after that
> but the GuC firmware is loaded much earlier in the sequence.
> As a result Driver could miss capturing the boot-time logs of GuC firmware
> if there are flush interrupts from the GuC side.
> Relay has a provision to support early logging where initially only relay
> channel can be created, to have buffers for storing logs, and later on
> channel can be associated with a debugfs file at appropriate time.
> Have availed that, which allows Driver to capture boot time logs also,
> which can be collected once Userspace comes up.
>
> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Akash Goel <akash.goel@intel.com>
> ---
> drivers/gpu/drm/i915/i915_guc_submission.c | 61 +++++++++++++++++++++---------
> 1 file changed, 44 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c
> index af48f62..1c287d7 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -1099,25 +1099,12 @@ static void guc_remove_log_relay_file(struct intel_guc *guc)
> relay_close(guc->log.relay_chan);
> }
>
> -static int guc_create_log_relay_file(struct intel_guc *guc)
> +static int guc_create_relay_channel(struct intel_guc *guc)
> {
> struct drm_i915_private *dev_priv = guc_to_i915(guc);
> struct rchan *guc_log_relay_chan;
> - struct dentry *log_dir;
> size_t n_subbufs, subbuf_size;
>
> - /* For now create the log file in /sys/kernel/debug/dri/0 dir */
> - log_dir = dev_priv->drm.primary->debugfs_root;
> -
> - /* If /sys/kernel/debug/dri/0 location do not exist, then debugfs is
> - * not mounted and so can't create the relay file.
> - * The relay API seems to fit well with debugfs only.
It only needs a dentry, I don't see that it has to be a debugfs one.
> - */
> - if (!log_dir) {
> - DRM_DEBUG_DRIVER("Parent debugfs directory not available yet\n");
> - return -ENODEV;
> - }
> -
> /* Keep the size of sub buffers same as shared log buffer */
> subbuf_size = guc->log.obj->base.size;
> /* Store up to 8 snaphosts, which is large enough to buffer sufficient
> @@ -1127,7 +1114,7 @@ static int guc_create_log_relay_file(struct intel_guc *guc)
> */
> n_subbufs = 8;
>
> - guc_log_relay_chan = relay_open("guc_log", log_dir,
> + guc_log_relay_chan = relay_open(NULL, NULL,
> subbuf_size, n_subbufs, &relay_callbacks, dev_priv);
>
> if (!guc_log_relay_chan) {
> @@ -1140,6 +1127,33 @@ static int guc_create_log_relay_file(struct intel_guc *guc)
> return 0;
> }
>
> +static int guc_create_log_relay_file(struct intel_guc *guc)
> +{
> + struct drm_i915_private *dev_priv = guc_to_i915(guc);
> + struct dentry *log_dir;
> + int ret;
> +
> + /* For now create the log file in /sys/kernel/debug/dri/0 dir */
> + log_dir = dev_priv->drm.primary->debugfs_root;
> +
> + /* If /sys/kernel/debug/dri/0 location do not exist, then debugfs is
> + * not mounted and so can't create the relay file.
> + * The relay API seems to fit well with debugfs only.
> + */
> + if (!log_dir) {
> + DRM_DEBUG_DRIVER("Parent debugfs directory not available yet\n");
> + return -ENODEV;
> + }
> +
> + ret = relay_late_setup_files(guc->log.relay_chan, "guc_log", log_dir);
> + if (ret) {
> + DRM_DEBUG_DRIVER("Couldn't associate the channel with file %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> static void guc_log_cleanup(struct intel_guc *guc)
> {
> struct drm_i915_private *dev_priv = guc_to_i915(guc);
> @@ -1167,7 +1181,7 @@ static int guc_create_log_extras(struct intel_guc *guc)
> {
> struct drm_i915_private *dev_priv = guc_to_i915(guc);
> void *vaddr;
> - int ret;
> + int ret = 0;
>
> lockdep_assert_held(&dev_priv->drm.struct_mutex);
>
> @@ -1190,7 +1204,15 @@ static int guc_create_log_extras(struct intel_guc *guc)
> guc->log.buf_addr = vaddr;
> }
>
> - return 0;
> + if (!guc->log.relay_chan) {
> + /* Create a relay channel, so that we have buffers for storing
> + * the GuC firmware logs, the channel will be linked with a file
> + * later on when debugfs is registered.
> + */
> + ret = guc_create_relay_channel(guc);
> + }
> +
> + return ret;
> }
>
> static void guc_create_log(struct intel_guc *guc)
> @@ -1231,6 +1253,7 @@ static void guc_create_log(struct intel_guc *guc)
> guc->log.obj = obj;
>
> if (guc_create_log_extras(guc)) {
> + guc_log_cleanup(guc);
> gem_release_guc_obj(guc->log.obj);
> guc->log.obj = NULL;
> i915.guc_log_level = -1;
> @@ -1265,6 +1288,10 @@ static int guc_log_late_setup(struct intel_guc *guc)
> if (ret)
> goto err;
>
> + /* Parent debugfs dir should be available by now, associate the already
> + * opened relay channel with a debugfs file, which will then allow User
> + * to pull the logs.
> + */
> ret = guc_create_log_relay_file(guc);
> if (ret)
> goto err;
>
Can't spot any problems.
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
I suppose you will also have to add some IGTs to exercise the whole
thing. Stopping/starting the logging, reading back, capturing some
commands etc. Or contract someone from validation to do it. :) Are there
any such plans?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-08-12 16:22 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-12 6:25 [PATCH v5 00/20] Support for sustained capturing of GuC firmware logs akash.goel
2016-08-12 6:25 ` [PATCH 01/20] drm/i915: Decouple GuC log setup from verbosity parameter akash.goel
2016-08-12 6:25 ` [PATCH 02/20] drm/i915: Add GuC ukernel logging related fields to fw interface file akash.goel
2016-08-12 6:25 ` [PATCH 03/20] drm/i915: New structure to contain GuC logging related fields akash.goel
2016-08-12 6:25 ` [PATCH 04/20] drm/i915: Add low level set of routines for programming PM IER/IIR/IMR register set akash.goel
2016-08-12 11:15 ` Tvrtko Ursulin
2016-08-12 6:25 ` [PATCH 05/20] drm/i915: Support for GuC interrupts akash.goel
2016-08-12 11:54 ` Tvrtko Ursulin
2016-08-12 13:10 ` Goel, Akash
2016-08-12 13:31 ` Tvrtko Ursulin
2016-08-12 14:31 ` Goel, Akash
2016-08-12 15:05 ` Tvrtko Ursulin
2016-08-12 15:32 ` Goel, Akash
2016-08-12 6:25 ` [PATCH 06/20] drm/i915: Handle log buffer flush interrupt event from GuC akash.goel
2016-08-12 6:28 ` Chris Wilson
2016-08-12 6:44 ` Goel, Akash
2016-08-12 6:51 ` Chris Wilson
2016-08-12 7:00 ` Goel, Akash
2016-08-12 13:17 ` Tvrtko Ursulin
2016-08-12 13:45 ` Goel, Akash
2016-08-12 14:07 ` Tvrtko Ursulin
2016-08-12 16:17 ` Goel, Akash
2016-08-12 6:25 ` [PATCH 07/20] relay: Use per CPU constructs for the relay channel buffer pointers akash.goel
2016-08-12 6:25 ` [PATCH 08/20] drm/i915: Add a relay backed debugfs interface for capturing GuC logs akash.goel
2016-08-12 13:53 ` Tvrtko Ursulin
2016-08-12 16:10 ` Goel, Akash
2016-08-12 6:25 ` [PATCH 09/20] drm/i915: New lock to serialize the Host2GuC actions akash.goel
2016-08-12 13:55 ` Tvrtko Ursulin
2016-08-12 15:01 ` Goel, Akash
2016-08-12 6:25 ` [PATCH 10/20] drm/i915: Add stats for GuC log buffer flush interrupts akash.goel
2016-08-12 14:26 ` Tvrtko Ursulin
2016-08-12 14:56 ` Goel, Akash
2016-08-12 6:25 ` [PATCH 11/20] drm/i915: Optimization to reduce the sampling time of GuC log buffer akash.goel
2016-08-12 14:42 ` Tvrtko Ursulin
2016-08-12 14:48 ` Goel, Akash
2016-08-12 15:06 ` Tvrtko Ursulin
2016-08-12 6:25 ` [PATCH 12/20] drm/i915: Increase GuC log buffer size to reduce flush interrupts akash.goel
2016-08-12 6:25 ` [PATCH 13/20] drm/i915: Augment i915 error state to include the dump of GuC log buffer akash.goel
2016-08-12 15:20 ` Tvrtko Ursulin
2016-08-12 15:32 ` Chris Wilson
2016-08-12 15:46 ` Goel, Akash
2016-08-12 15:52 ` Chris Wilson
2016-08-12 16:04 ` Goel, Akash
2016-08-12 16:09 ` Chris Wilson
2016-08-12 6:25 ` [PATCH 14/20] drm/i915: Forcefully flush GuC log buffer on reset akash.goel
2016-08-12 6:33 ` Chris Wilson
2016-08-12 7:02 ` Goel, Akash
2016-08-12 6:25 ` [PATCH 15/20] drm/i915: Debugfs support for GuC logging control akash.goel
2016-08-12 15:57 ` Tvrtko Ursulin
2016-08-12 17:08 ` Goel, Akash
2016-08-12 6:25 ` [PATCH 16/20] drm/i915: Support to create write combined type vmaps akash.goel
2016-08-12 10:49 ` Tvrtko Ursulin
2016-08-12 15:13 ` Goel, Akash
2016-08-12 15:16 ` Chris Wilson
2016-08-12 16:46 ` Goel, Akash
2016-08-12 6:25 ` [PATCH 17/20] drm/i915: Use uncached(WC) mapping for acessing the GuC log buffer akash.goel
2016-08-12 16:05 ` Tvrtko Ursulin
2016-08-12 6:25 ` [PATCH 18/20] drm/i915: Use SSE4.1 movntdqa to accelerate reads from WC memory akash.goel
2016-08-12 10:54 ` Tvrtko Ursulin
2016-08-12 12:22 ` Chris Wilson
2016-08-12 6:25 ` [PATCH 19/20] drm/i915: Use SSE4.1 movntdqa based memcpy for sampling GuC log buffer akash.goel
2016-08-12 16:06 ` Tvrtko Ursulin
2016-08-12 6:25 ` [PATCH 20/20] drm/i915: Early creation of relay channel for capturing boot time logs akash.goel
2016-08-12 16:22 ` Tvrtko Ursulin [this message]
2016-08-12 16:31 ` Goel, Akash
2016-08-15 9:20 ` Tvrtko Ursulin
2016-08-15 10:20 ` Goel, Akash
2016-08-12 6:58 ` ✗ Ro.CI.BAT: warning for Support for sustained capturing of GuC firmware logs (rev6) 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=57ADF7AF.5000803@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=akash.goel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.