From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: akash.goel@intel.com, intel-gfx@lists.freedesktop.org
Cc: Sourab Gupta <sourab.gupta@intel.com>
Subject: Re: [PATCH 08/20] drm/i915: Add a relay backed debugfs interface for capturing GuC logs
Date: Fri, 12 Aug 2016 14:53:08 +0100 [thread overview]
Message-ID: <57ADD4C4.8010902@linux.intel.com> (raw)
In-Reply-To: <1470983123-22127-9-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>
>
> Added a new debugfs interface '/sys/kernel/debug/dri/guc_log' for the
> User to capture GuC firmware logs. Availed relay framework to implement
> the interface, where Driver will have to just use a relay API to store
> snapshots of the GuC log buffer in the buffer managed by relay.
> The snapshot will be taken when GuC firmware sends a log buffer flush
> interrupt and up to four snaphots could be stored in the relay buffer.
snapshots
> The relay buffer will be operated in a mode where it will overwrite the
> data not yet collected by User.
> Besides mmap method, through which User can directly access the relay
> buffer contents, relay also supports the 'poll' method. Through the 'poll'
> call on log file, User can come to know whenever a new snapshot of the
> log buffer is taken by Driver, so can run in tandem with the Driver and
> capture the logs in a sustained/streaming manner, without any loss of data.
>
> v2: Defer the creation of relay channel & associated debugfs file, as
> debugfs setup is now done at the end of i915 Driver load. (Chris)
>
> v3:
> - Switch to no-overwrite mode for relay.
> - Fix the relay sub buffer switching sequence.
>
> v4:
> - Update i915 Kconfig to select RELAY config. (TvrtKo)
> - Log a message when there is no sub buffer available to capture
> the GuC log buffer. (Tvrtko)
> - Increase the number of relay sub buffers to 8 from 4, to have
> sufficient buffering for boot time logs
>
> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Sourab Gupta <sourab.gupta@intel.com>
> Signed-off-by: Akash Goel <akash.goel@intel.com>
> ---
> drivers/gpu/drm/i915/Kconfig | 1 +
> drivers/gpu/drm/i915/i915_drv.c | 2 +
> drivers/gpu/drm/i915/i915_guc_submission.c | 206 ++++++++++++++++++++++++++++-
> drivers/gpu/drm/i915/intel_guc.h | 3 +
> 4 files changed, 209 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 7769e46..fc900d2 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -11,6 +11,7 @@ config DRM_I915
> select DRM_KMS_HELPER
> select DRM_PANEL
> select DRM_MIPI_DSI
> + select RELAY
> # i915 depends on ACPI_VIDEO when ACPI is enabled
> # but for select to work, need to select ACPI_VIDEO's dependencies, ick
> select BACKLIGHT_LCD_SUPPORT if ACPI
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index fc2da32..cb8c943 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1145,6 +1145,7 @@ static void i915_driver_register(struct drm_i915_private *dev_priv)
> /* Reveal our presence to userspace */
> if (drm_dev_register(dev, 0) == 0) {
> i915_debugfs_register(dev_priv);
> + i915_guc_register(dev_priv);
> i915_setup_sysfs(dev);
> } else
> DRM_ERROR("Failed to register driver for userspace access!\n");
> @@ -1183,6 +1184,7 @@ static void i915_driver_unregister(struct drm_i915_private *dev_priv)
> intel_opregion_unregister(dev_priv);
>
> i915_teardown_sysfs(&dev_priv->drm);
> + i915_guc_unregister(dev_priv);
> i915_debugfs_unregister(dev_priv);
> drm_dev_unregister(&dev_priv->drm);
>
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c
> index 2635b67..1a2d648 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -23,6 +23,8 @@
> */
> #include <linux/firmware.h>
> #include <linux/circ_buf.h>
> +#include <linux/debugfs.h>
> +#include <linux/relay.h>
> #include "i915_drv.h"
> #include "intel_guc.h"
>
> @@ -851,12 +853,33 @@ err:
>
> static void guc_move_to_next_buf(struct intel_guc *guc)
> {
> - return;
> + /* Make sure the updates made in the sub buffer are visible when
> + * Consumer sees the following update to offset inside the sub buffer.
> + */
> + smp_wmb();
> +
> + /* All data has been written, so now move the offset of sub buffer. */
> + relay_reserve(guc->log.relay_chan, guc->log.obj->base.size);
> +
> + /* Switch to the next sub buffer */
> + relay_flush(guc->log.relay_chan);
> }
>
> static void* guc_get_write_buffer(struct intel_guc *guc)
> {
> - return NULL;
> + /* FIXME: Cover the check under a lock ? */
Need to resolve before r-b in any case.
> + if (!guc->log.relay_chan)
> + return NULL;
> +
> + /* Just get the base address of a new sub buffer and copy data into it
> + * ourselves. NULL will be returned in no-overwrite mode, if all sub
> + * buffers are full. Could have used the relay_write() to indirectly
> + * copy the data, but that would have been bit convoluted, as we need to
> + * write to only certain locations inside a sub buffer which cannot be
> + * done without using relay_reserve() along with relay_write(). So its
> + * better to use relay_reserve() alone.
> + */
> + return relay_reserve(guc->log.relay_chan, 0);
> }
>
> static void guc_read_update_log_buffer(struct intel_guc *guc)
> @@ -923,6 +946,130 @@ static void guc_read_update_log_buffer(struct intel_guc *guc)
>
> if (log_buffer_snapshot_state)
> guc_move_to_next_buf(guc);
> + else {
> + /* Used rate limited to avoid deluge of messages, logs might be
> + * getting consumed by User at a slow rate.
> + */
> + DRM_ERROR_RATELIMITED("no sub-buffer to capture log buffer\n");
> + }
> +}
> +
> +/*
> + * Sub buffer switch callback. Called whenever relay has to switch to a new
> + * sub buffer, relay stays on the same sub buffer if 0 is returned.
> + */
> +static int subbuf_start_callback(struct rchan_buf *buf,
> + void *subbuf,
> + void *prev_subbuf,
> + size_t prev_padding)
> +{
> + /* Use no-overwrite mode by default, where relay will stop accepting
> + * new data if there are no empty sub buffers left.
> + * There is no strict synchronization enforced by relay between Consumer
> + * and Producer. In overwrite mode, there is a possibility of getting
> + * inconsistent/garbled data, the producer could be writing on to the
> + * same sub buffer from which Consumer is reading. This can't be avoided
> + * unless Consumer is fast enough and can always run in tandem with
> + * Producer.
> + */
> + if (relay_buf_full(buf))
> + return 0;
> +
> + return 1;
> +}
> +
> +/*
> + * file_create() callback. Creates relay file in debugfs.
> + */
> +static struct dentry *create_buf_file_callback(const char *filename,
> + struct dentry *parent,
> + umode_t mode,
> + struct rchan_buf *buf,
> + int *is_global)
> +{
> + struct dentry *buf_file = NULL;
> +
Would this function be a tiny bit simpler as:
if (!parent)
return NULL;
?
> + if (parent) {
> + /* Not using the channel filename passed as an argument, since
> + * for each channel relay appends the corresponding CPU number
> + * to the filename passed in relay_open(). This should be fine
> + * as relay just needs a dentry of the file associated with the
> + * channel buffer and that file's name need not be same as the
> + * filename passed as an argument.
> + */
> + buf_file = debugfs_create_file("guc_log", mode,
> + parent, buf, &relay_file_operations);
Alignment is wrong.
> + }
> +
> + /* This to enable the use of a single buffer for the relay channel and
> + * correspondingly have a single file exposed to User, through which
> + * it can collect the logs inorder without any post-processing.
"in order"
> + */
> + *is_global = 1;
> +
> + return buf_file;
> +}
> +
> +/*
> + * file_remove() default callback. Removes relay file in debugfs.
> + */
> +static int remove_buf_file_callback(struct dentry *dentry)
> +{
> + debugfs_remove(dentry);
> + return 0;
> +}
> +
> +/* relay channel callbacks */
> +static struct rchan_callbacks relay_callbacks = {
> + .subbuf_start = subbuf_start_callback,
> + .create_buf_file = create_buf_file_callback,
> + .remove_buf_file = remove_buf_file_callback,
> +};
> +
> +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)
> +{
> + 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 */
Where it should be or will be later?
> + 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;
> + }
> +
> + /* Keep the size of sub buffers same as shared log buffer */
> + subbuf_size = guc->log.obj->base.size;
Insert blank line for readability probably.
> + /* Store up to 8 snaphosts, which is large enough to buffer sufficient
snapshots
> + * boot time logs and provides enough leeway to User, in terms of
> + * latency, for consuming the logs from relay. Also doesn't take
> + * up too much memory.
> + */
Indentation is off.
> + n_subbufs = 8;
> +
> + guc_log_relay_chan = relay_open("guc_log", log_dir,
> + subbuf_size, n_subbufs, &relay_callbacks, dev_priv);
Alignment is wrong.
> +
> + if (!guc_log_relay_chan) {
> + DRM_DEBUG_DRIVER("Couldn't create relay chan for guc logs\n");
> + return -ENOMEM;
> + }
> +
> + /* FIXME: Cover the update under a lock ? */
Another FIXME to be resolved.
> + guc->log.relay_chan = guc_log_relay_chan;
> + return 0;
> }
>
> static void guc_log_cleanup(struct intel_guc *guc)
> @@ -937,6 +1084,11 @@ static void guc_log_cleanup(struct intel_guc *guc)
> /* First disable the flush interrupt */
> gen9_disable_guc_interrupts(dev_priv);
>
> + if (guc->log.relay_chan)
> + guc_remove_log_relay_file(guc);
> +
> + guc->log.relay_chan = NULL;
> +
> if (guc->log.buf_addr)
> i915_gem_object_unpin_map(guc->log.obj);
>
> @@ -1015,6 +1167,35 @@ static void guc_create_log(struct intel_guc *guc)
> guc->log.flags = (offset << GUC_LOG_BUF_ADDR_SHIFT) | flags;
> }
>
> +static int guc_log_late_setup(struct intel_guc *guc)
static void if failure cannot be handled or otherwise act on the return
value?
> +{
> + struct drm_i915_private *dev_priv = guc_to_i915(guc);
> + int ret;
> +
> + lockdep_assert_held(&dev_priv->drm.struct_mutex);
> +
> + if (i915.guc_log_level < 0)
> + return -EINVAL;
> +
> + /* If log_level was set as -1 at boot time, then vmalloc mapping would
> + * not have been created for the log buffer, so create one now.
> + */
> + ret = guc_create_log_extras(guc);
> + if (ret)
> + goto err;
> +
> + ret = guc_create_log_relay_file(guc);
> + if (ret)
> + goto err;
> +
> + return 0;
> +err:
> + guc_log_cleanup(guc);
> + /* logging will remain off */
> + i915.guc_log_level = -1;
> + return ret;
> +}
> +
> static void init_guc_policies(struct guc_policies *policies)
> {
> struct guc_policy *policy;
> @@ -1185,7 +1366,6 @@ void i915_guc_submission_fini(struct drm_i915_private *dev_priv)
> gem_release_guc_obj(dev_priv->guc.ads_obj);
> guc->ads_obj = NULL;
>
> - guc_log_cleanup(guc);
> gem_release_guc_obj(dev_priv->guc.log.obj);
> guc->log.obj = NULL;
>
> @@ -1261,3 +1441,23 @@ void i915_guc_capture_logs(struct drm_i915_private *dev_priv)
> host2guc_logbuffer_flush_complete(&dev_priv->guc);
> intel_runtime_pm_put(dev_priv);
> }
> +
> +void i915_guc_unregister(struct drm_i915_private *dev_priv)
> +{
> + if (!i915.enable_guc_submission)
> + return;
> +
> + mutex_lock(&dev_priv->drm.struct_mutex);
> + guc_log_cleanup(&dev_priv->guc);
> + mutex_unlock(&dev_priv->drm.struct_mutex);
> +}
> +
> +void i915_guc_register(struct drm_i915_private *dev_priv)
> +{
> + if (!i915.enable_guc_submission)
> + return;
> +
> + mutex_lock(&dev_priv->drm.struct_mutex);
> + guc_log_late_setup(&dev_priv->guc);
> + mutex_unlock(&dev_priv->drm.struct_mutex);
> +}
> diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
> index 7c0bdba..96ef7dc 100644
> --- a/drivers/gpu/drm/i915/intel_guc.h
> +++ b/drivers/gpu/drm/i915/intel_guc.h
> @@ -126,6 +126,7 @@ struct intel_guc_log {
> struct drm_i915_gem_object *obj;
> struct workqueue_struct *wq;
> void *buf_addr;
> + struct rchan *relay_chan;
> };
>
> struct intel_guc {
> @@ -172,5 +173,7 @@ int i915_guc_wq_check_space(struct drm_i915_gem_request *rq);
> void i915_guc_submission_disable(struct drm_i915_private *dev_priv);
> void i915_guc_submission_fini(struct drm_i915_private *dev_priv);
> void i915_guc_capture_logs(struct drm_i915_private *dev_priv);
> +void i915_guc_register(struct drm_i915_private *dev_priv);
> +void i915_guc_unregister(struct drm_i915_private *dev_priv);
>
> #endif
>
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 13:53 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 [this message]
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
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=57ADD4C4.8010902@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=akash.goel@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=sourab.gupta@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 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.