All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: akash.goel@intel.com, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 09/17] drm/i915: Debugfs support for GuC logging control
Date: Tue, 19 Jul 2016 12:24:52 +0100	[thread overview]
Message-ID: <578E0E04.9070306@linux.intel.com> (raw)
In-Reply-To: <1468158084-22028-10-git-send-email-akash.goel@intel.com>


On 10/07/16 14:41, akash.goel@intel.com wrote:
> From: Sagar Arun Kamble <sagar.a.kamble@intel.com>
>
> This patch provides debugfs interface i915_guc_output_control for
> on the fly enabling/disabling of logging in GuC firmware and controlling
> the verbosity level of logs.
> The value written to the file, should have bit 0 set to enable logging and
> bits 4-7 should contain the verbosity info.
>
> v2: Add a forceful flush, to collect left over logs, on disabling logging.
>      Useful for Validation.
>
> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
> Signed-off-by: Akash Goel <akash.goel@intel.com>
> ---
>   drivers/gpu/drm/i915/i915_debugfs.c        | 32 ++++++++++++++++-
>   drivers/gpu/drm/i915/i915_guc_submission.c | 57 ++++++++++++++++++++++++++++++
>   drivers/gpu/drm/i915/intel_guc.h           |  1 +
>   3 files changed, 89 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
> index 5e35565..3c9c7f7 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2644,6 +2644,35 @@ static int i915_guc_log_dump(struct seq_file *m, void *data)
>   	return 0;
>   }
>
> +static int
> +i915_guc_log_control_set(void *data, u64 val)
> +{
> +	struct drm_device *dev = data;
> +	struct drm_i915_private *dev_priv = dev->dev_private;

to_i915 should be used.

> +	int ret;
> +
> +	ret = mutex_lock_interruptible(&dev->struct_mutex);
> +	if (ret)
> +		return ret;
> +
> +	if (!i915.enable_guc_submission || !dev_priv->guc.log.obj) {

Wouldn't guc.log.obj be enough?

> +		ret = -EINVAL;
> +		goto end;
> +	}
> +
> +	intel_runtime_pm_get(dev_priv);
> +	ret = i915_guc_log_control(dev, val);
> +	intel_runtime_pm_put(dev_priv);
> +
> +end:
> +	mutex_unlock(&dev->struct_mutex);
> +	return ret;
> +}
> +
> +DEFINE_SIMPLE_ATTRIBUTE(i915_guc_log_control_fops,
> +			NULL, i915_guc_log_control_set,
> +			"0x%08llx\n");

Does the readback still work with no get method?

> +
>   static int i915_edp_psr_status(struct seq_file *m, void *data)
>   {
>   	struct drm_info_node *node = m->private;
> @@ -5464,7 +5493,8 @@ static const struct i915_debugfs_files {
>   	{"i915_fbc_false_color", &i915_fbc_fc_fops},
>   	{"i915_dp_test_data", &i915_displayport_test_data_fops},
>   	{"i915_dp_test_type", &i915_displayport_test_type_fops},
> -	{"i915_dp_test_active", &i915_displayport_test_active_fops}
> +	{"i915_dp_test_active", &i915_displayport_test_active_fops},
> +	{"i915_guc_log_control", &i915_guc_log_control_fops}
>   };
>
>   void intel_display_crc_init(struct drm_device *dev)
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c
> index 8cc31c6..2e3b723 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -193,6 +193,16 @@ static int host2guc_force_logbuffer_flush(struct intel_guc *guc)
>   	return host2guc_action(guc, data, 2);
>   }
>
> +static int host2guc_logging_control(struct intel_guc *guc, u32 control_val)
> +{
> +	u32 data[2];
> +
> +	data[0] = HOST2GUC_ACTION_UK_LOG_ENABLE_LOGGING;
> +	data[1] = control_val;
> +
> +	return host2guc_action(guc, data, 2);
> +}
> +
>   /*
>    * Initialise, update, or clear doorbell data shared with the GuC
>    *
> @@ -1455,3 +1465,50 @@ void i915_guc_register(struct drm_device *dev)
>   	guc_log_late_setup(dev);
>   	mutex_unlock(&dev->struct_mutex);
>   }
> +
> +int i915_guc_log_control(struct drm_device *dev, uint64_t control_val)
> +{
> +	struct drm_i915_private *dev_priv = dev->dev_private;

to_i915

Actually, function should take dev_priv if not even guc depending on the 
established convention in the file.

> +	union guc_log_control log_param;
> +	int ret;
> +
> +	log_param.logging_enabled = control_val & 0x1;
> +	log_param.verbosity = (control_val >> 4) & 0xF;
> +
> +	if (log_param.verbosity < GUC_LOG_VERBOSITY_MIN ||
> +	    log_param.verbosity > GUC_LOG_VERBOSITY_MAX)
> +		return -EINVAL;
> +
> +	/* This combination doesn't make sense & won't have any effect */
> +	if (!log_param.logging_enabled && (i915.guc_log_level < 0))
> +		return -EINVAL;

Hm, disabling while already disabled - why should that return an error? 
Might be annoying in scripts.

> +
> +	ret = host2guc_logging_control(&dev_priv->guc, log_param.value);
> +	if (ret < 0) {
> +		DRM_DEBUG_DRIVER("host2guc action failed\n");

Add ret to the log since it is easy?

> +		return ret;
> +	}
> +
> +	i915.guc_log_level = log_param.verbosity;
> +
> +	/* If log_level was set as -1 at boot time, then the relay channel file
> +	 * wouldn't have been created by now and interrupts also would not have
> +	 * been enabled.
> +	 */
> +	if (!dev_priv->guc.log.relay_chan) {
> +		ret = guc_log_late_setup(dev);
> +		if (!ret)
> +			gen9_enable_guc_interrupts(dev_priv);

Hm, look at the above and below, do we need to create the relay channel 
if logging_enabled == false ?

> +	} else if (!log_param.logging_enabled) {
> +		/* Once logging is disabled, GuC won't generate logs & send an
> +		 * interrupt. But there could be some data in the log buffer
> +		 * which is yet to be captured. So request GuC to update the log
> +		 * buffer state and send the flush interrupt so that Host can
> +		 * collect the left over logs also.
> +		 */
> +		flush_work(&dev_priv->guc.events_work);
> +		host2guc_force_logbuffer_flush(&dev_priv->guc);
> +	}
> +
> +	return ret;
> +}
> diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
> index ed773b5..d56bde6 100644
> --- a/drivers/gpu/drm/i915/intel_guc.h
> +++ b/drivers/gpu/drm/i915/intel_guc.h
> @@ -178,5 +178,6 @@ void i915_guc_capture_logs(struct drm_device *dev);
>   void i915_guc_capture_logs_on_reset(struct drm_device *dev);
>   void i915_guc_register(struct drm_device *dev);
>   void i915_guc_unregister(struct drm_device *dev);
> +int i915_guc_log_control(struct drm_device *dev, uint64_t control_val);
>
>   #endif
>

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2016-07-19 11:24 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-10 13:41 [PATCH v4 00/17] Support for sustained capturing of GuC firmware logs akash.goel
2016-07-10 13:41 ` [PATCH 01/17] drm/i915: Decouple GuC log setup from verbosity parameter akash.goel
2016-07-11  9:37   ` Tvrtko Ursulin
2016-07-11 11:41     ` Goel, Akash
2016-07-11 11:50       ` Tvrtko Ursulin
2016-07-11 12:11         ` Goel, Akash
2016-07-11 13:07           ` Tvrtko Ursulin
2016-07-10 13:41 ` [PATCH 02/17] drm/i915: Add GuC ukernel logging related fields to fw interface file akash.goel
2016-07-10 13:41 ` [PATCH 03/17] drm/i915: New structure to contain GuC logging related fields akash.goel
2016-07-10 13:41 ` [PATCH 04/17] drm/i915: Add low level set of routines for programming PM IER/IIR/IMR register set akash.goel
2016-07-11 10:04   ` Tvrtko Ursulin
2016-07-10 13:41 ` [PATCH 05/17] drm/i915: Support for GuC interrupts akash.goel
2016-07-11 10:30   ` Tvrtko Ursulin
2016-07-11 13:15     ` Goel, Akash
2016-07-11 13:23       ` Tvrtko Ursulin
2016-07-11 13:38         ` Goel, Akash
2016-07-11 13:43           ` Tvrtko Ursulin
2016-07-11 14:20             ` Goel, Akash
2016-07-10 13:41 ` [PATCH 06/17] drm/i915: Handle log buffer flush interrupt event from GuC akash.goel
2016-07-19 10:58   ` Tvrtko Ursulin
2016-07-20  3:29     ` Goel, Akash
2016-07-10 13:41 ` [PATCH 07/17] drm/i915: Add a relay backed debugfs interface for capturing GuC logs akash.goel
2016-07-10 17:07   ` kbuild test robot
2016-07-19 11:31   ` Tvrtko Ursulin
2016-07-20  3:41     ` Goel, Akash
2016-07-10 13:41 ` [PATCH 08/17] drm/i915: Forcefully flush GuC log buffer on reset akash.goel
2016-07-19 11:12   ` Tvrtko Ursulin
2016-07-19 11:21     ` Chris Wilson
2016-07-20  4:21       ` Goel, Akash
2016-07-20  9:12         ` Chris Wilson
2016-07-20  9:48           ` Goel, Akash
2016-07-10 13:41 ` [PATCH 09/17] drm/i915: Debugfs support for GuC logging control akash.goel
2016-07-10 17:59   ` kbuild test robot
2016-07-19 11:24   ` Tvrtko Ursulin [this message]
2016-07-20  4:42     ` Goel, Akash
2016-07-20  9:08       ` Tvrtko Ursulin
2016-07-20  9:32         ` Goel, Akash
2016-07-20  9:47           ` Tvrtko Ursulin
2016-07-20 10:12             ` Goel, Akash
2016-07-20 10:40               ` Tvrtko Ursulin
2016-07-20 11:29                 ` Goel, Akash
2016-07-20 11:50                   ` Tvrtko Ursulin
2016-07-20 12:16                     ` Goel, Akash
2016-07-10 13:41 ` [PATCH 10/17] drm/i915: New module param to control the size of buffer used for storing GuC firmware logs akash.goel
2016-07-15 11:15   ` Tvrtko Ursulin
2016-07-15 15:36     ` Goel, Akash
2016-07-18 10:06       ` Tvrtko Ursulin
2016-07-18 12:19         ` Goel, Akash
2016-07-18 13:06           ` Tvrtko Ursulin
2016-07-18 13:40             ` Goel, Akash
2016-07-10 13:41 ` [PATCH 11/17] drm/i915: Support to create write combined type vmaps akash.goel
2016-07-15 11:31   ` Tvrtko Ursulin
2016-07-15 11:45     ` Chris Wilson
2016-07-15 16:30     ` Goel, Akash
2016-07-18 10:18       ` Tvrtko Ursulin
2016-07-10 13:41 ` [PATCH 12/17] drm/i915: Use uncached(WC) mapping for acessing the GuC log buffer akash.goel
2016-07-10 13:41 ` [PATCH 13/17] drm/i915: New lock to serialize the Host2GuC actions akash.goel
2016-07-15 11:40   ` Tvrtko Ursulin
2016-07-15 15:51     ` Goel, Akash
2016-07-18 10:12       ` Tvrtko Ursulin
2016-07-18 10:46         ` Goel, Akash
2016-07-18 11:18           ` Tvrtko Ursulin
2016-07-18 11:31             ` Goel, Akash
2016-07-18 11:36               ` Tvrtko Ursulin
2016-07-10 13:41 ` [PATCH 14/17] drm/i915: Add stats for GuC log buffer flush interrupts akash.goel
2016-07-15 11:51   ` Tvrtko Ursulin
2016-07-15 15:58     ` Goel, Akash
2016-07-18 10:16       ` Tvrtko Ursulin
2016-07-18 10:59         ` Goel, Akash
2016-07-18 11:33           ` Tvrtko Ursulin
2016-07-18 11:47             ` Goel, Akash
2016-07-10 13:41 ` [PATCH 15/17] drm/i915: Increase GuC log buffer size to reduce " akash.goel
2016-07-15 11:57   ` Tvrtko Ursulin
2016-07-15 14:42     ` Goel, Akash
2016-07-15 15:07       ` Tvrtko Ursulin
2016-07-15 16:20         ` Goel, Akash
2016-07-18  9:54           ` Tvrtko Ursulin
2016-07-18 12:35             ` Goel, Akash
2016-07-18 13:08               ` Tvrtko Ursulin
2016-07-10 13:41 ` [PATCH 16/17] drm/i915: Optimization to reduce the sampling time of GuC log buffer akash.goel
2016-07-10 13:41 ` [PATCH 17/17] drm/i915: Use rt priority kthread to do GuC log buffer sampling akash.goel
2016-07-20 19:34   ` Chris Wilson
2016-07-21  3:41     ` Goel, Akash
2016-07-21  5:43       ` Chris Wilson
2016-07-21  6:18         ` Goel, Akash
2016-07-21  9:44           ` Tvrtko Ursulin
2016-07-10 14:12 ` ✗ Ro.CI.BAT: failure for Support for sustained capturing of GuC firmware logs (rev5) 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=578E0E04.9070306@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.