All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Gordon <david.s.gordon@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 06/15] drm/i915: Debugfs interface to read GuC load status
Date: Fri, 19 Jun 2015 08:49:52 +0100	[thread overview]
Message-ID: <5583C9A0.1040405@intel.com> (raw)
In-Reply-To: <20150616094056.GO28462@nuc-i3427.alporthouse.com>

On 16/06/15 10:40, Chris Wilson wrote:
> On Mon, Jun 15, 2015 at 07:36:24PM +0100, Dave Gordon wrote:
>> From: Alex Dai <yu.dai@intel.com>
>>
>> The new node provides access to the status of the common uC loader
>> code and the GuC-specific loader; also the scratch registers used
>> for communicatio between the i915 driver and the GuC firmware.
>>
>> Issue: VIZ-4884
>> Signed-off-by: Alex Dai <yu.dai@intel.com>
>> Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
>> ---
>>  drivers/gpu/drm/i915/i915_debugfs.c |   37 +++++++++++++++++++++++++++++++++++
>>  1 file changed, 37 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
>> index 47636f3..c52a745 100644
>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
>> @@ -2352,6 +2352,42 @@ static int i915_llc(struct seq_file *m, void *data)
>>  	return 0;
>>  }
>>  
>> +static void i915_uc_load_status_info(struct seq_file *m, struct intel_uc_fw *uc_fw)
>> +{
>> +	seq_printf(m, "%s firmware status:\n\tpath: <%s>\n\tfetch: %d\n\tload: %d\n",
>> +			uc_fw->uc_name,
>> +			uc_fw->uc_fw_path,
>> +			uc_fw->uc_fw_fetch_status,
>> +			uc_fw->uc_fw_load_status);
> 
> If you made this one seq_printf() per line visualing the resulting
> format would have been easier - and easier to modify.

Done.

> Don't use <%s>, that's just visual noise to make cutting and pasting
> harder.

My terminal doesn't include <> in word selections (but DOES include "/"
and ".") so selecting a pathname just works :) But I've removed the
<angle.brackets> anyway.

> If you can decode numeric status values, do so.

Done. I've added a _repr function for decoding the enum and used it
everywhere.

>> +}
>> +
>> +static int i915_guc_load_status_info(struct seq_file *m, void *data)
>> +{
>> +	struct drm_info_node *node = m->private;
>> +	struct drm_i915_private *dev_priv = node->minor->dev->dev_private;
>> +	u32 tmp, i;
>> +
>> +	if (!HAS_GUC_UCODE(dev_priv->dev))
> 
> Here and elsewhere it should be return -ENODEV;

There's only one other use of HAS_GUC_UCODE (in intel_guc_ucode_init())
and that one doesn't and mustn't trigger an error if false. I don't see
why it should be an *error* here either; the caller hasn't done anything
wrong, and there's no h/w or s/w failure. An empty result (EOF) is a
nice way of saying that there's nothing to say, without making the user
think something broke.

In fact it may be perfectly meaningful to continue rather than
returning; consider the case of a future GuC that comes with firmware
preloaded, so HAS_GUC() is true but HAS_GUC_UCODE() is FALSE. We could
still read and decode the GUC_STATUS even though we haven't loaded any
firmware.

>> +		return 0;
>> +
>> +	i915_uc_load_status_info(m, &dev_priv->guc.guc_fw);
>> +
>> +	tmp = I915_READ(GUC_STATUS);
>> +
>> +	seq_printf(m, "\nGuC status 0x%08x:\n", tmp);
>> +	seq_printf(m, "\tBootrom status = 0x%x\n",
>> +		(tmp & GS_BOOTROM_MASK) >> GS_BOOTROM_SHIFT);
>> +	seq_printf(m, "\tuKernel status = 0x%x\n",
>> +		(tmp & GS_UKERNEL_MASK) >> GS_UKERNEL_SHIFT);
>> +	seq_printf(m, "\tMIA Core status = 0x%x\n",
>> +		(tmp & GS_MIA_MASK) >> GS_MIA_SHIFT);
>> +	seq_puts(m, "\nScratch registers value:\n");
>> +	for (i = 0; i < 16; i++)
>> +		seq_printf(m, "\t%2d: \t0x%x\n", i, I915_READ(SOFT_SCRATCH(i)));
> 
> I have a feeling these probably don't want to be upstreamed.
> -Chris

It's just a register dump; nothing secret there. You could read them
with IGT's register dumper anyway.

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

  reply	other threads:[~2015-06-19  7:49 UTC|newest]

Thread overview: 91+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-15 18:36 [PATCH 00/15] Batch submission via GuC Dave Gordon
2015-06-15 18:36 ` [PATCH 01/15] drm/i915: Add i915_gem_object_write() to i915_gem.c Dave Gordon
2015-06-15 20:09   ` Chris Wilson
2015-06-17  7:23     ` Dave Gordon
2015-06-17 12:02       ` Daniel Vetter
2015-06-18 11:49         ` Dave Gordon
2015-06-18 12:10           ` Chris Wilson
2015-06-18 18:07             ` Dave Gordon
2015-06-19  8:44               ` Chris Wilson
2015-06-22 11:59                 ` Dave Gordon
2015-06-22 12:37                   ` Chris Wilson
2015-06-23 16:54                     ` Dave Gordon
2015-06-18 14:31           ` Daniel Vetter
2015-06-18 18:28             ` Dave Gordon
2015-06-24  9:32               ` Daniel Vetter
2015-06-25 12:28                 ` Dave Gordon
2015-06-24  9:40               ` Chris Wilson
2015-06-15 18:36 ` [PATCH 02/15] drm/i915: Embedded microcontroller (uC) firmware loading support Dave Gordon
2015-06-17 12:05   ` Daniel Vetter
2015-06-18 12:11     ` Dave Gordon
2015-06-18 14:49       ` Daniel Vetter
2015-06-18 15:27         ` Chris Wilson
2015-06-18 15:35           ` Daniel Vetter
2015-06-18 15:49             ` Chris Wilson
2015-06-19  8:43         ` Dave Gordon
2015-06-24 10:29           ` Daniel Vetter
2015-07-06 12:44             ` Dave Gordon
2015-07-06 13:24               ` Daniel Vetter
2015-06-15 18:36 ` [PATCH 03/15] drm/i915: Add GuC-related module parameters Dave Gordon
2015-06-15 18:36 ` [PATCH 04/15] drm/i915: Add GuC-related header files Dave Gordon
2015-06-15 20:20   ` Chris Wilson
2015-06-17 15:01     ` Dave Gordon
2015-06-23 18:10       ` Dave Gordon
2015-06-24  7:41     ` Dave Gordon
2015-06-24  9:37       ` Daniel Vetter
2015-06-15 18:36 ` [PATCH 05/15] drm/i915: GuC-specific firmware loader Dave Gordon
2015-06-15 20:30   ` Chris Wilson
2015-06-18 17:53     ` Yu Dai
2015-06-18 20:12       ` Chris Wilson
2015-06-19 14:34         ` Dave Gordon
2015-06-18 18:54     ` Dave Gordon
2015-06-15 18:36 ` [PATCH 06/15] drm/i915: Debugfs interface to read GuC load status Dave Gordon
2015-06-16  9:40   ` Chris Wilson
2015-06-19  7:49     ` Dave Gordon [this message]
2015-06-15 18:36 ` [PATCH 07/15] drm/i915: Defer default hardware context initialisation until first open Dave Gordon
2015-06-16  9:35   ` Chris Wilson
2015-06-19  9:42     ` Dave Gordon
2015-06-17 12:18   ` Daniel Vetter
2015-06-19  9:19     ` Dave Gordon
2015-06-24 10:15       ` Daniel Vetter
2015-06-15 18:36 ` [PATCH 08/15] drm/i915: Move execlists defines from .c to .h Dave Gordon
2015-06-16  9:37   ` Chris Wilson
2015-06-17  7:31     ` Dave Gordon
2015-06-17  7:54       ` Chris Wilson
2015-06-17  7:59       ` Chris Wilson
2015-06-22 13:05         ` Dave Gordon
2015-06-15 18:36 ` [PATCH 09/15] drm/i915: GuC submission setup, phase 1 Dave Gordon
2015-06-15 21:32   ` Chris Wilson
2015-06-19 17:02     ` Dave Gordon
2015-06-19 17:22       ` Dave Gordon
2015-06-16 11:44   ` Chris Wilson
2015-06-15 18:36 ` [PATCH 10/15] drm/i915: Enable GuC firmware log Dave Gordon
2015-06-15 21:40   ` Chris Wilson
2015-06-16  9:26   ` Tvrtko Ursulin
2015-06-16 11:40     ` Chris Wilson
2015-06-16 12:29       ` Tvrtko Ursulin
2015-06-15 18:36 ` [PATCH 11/15] drm/i915: Implementation of GuC client Dave Gordon
2015-06-15 21:55   ` Chris Wilson
2015-06-19 17:55     ` Dave Gordon
2015-06-15 18:36 ` [PATCH 12/15] drm/i915: Interrupt routing for GuC submission Dave Gordon
2015-06-16  9:24   ` Chris Wilson
2015-06-17  8:20     ` Dave Gordon
2015-06-17 12:22       ` Daniel Vetter
2015-06-17 12:41         ` Daniel Vetter
2015-06-23 11:33           ` Dave Gordon
2015-06-23 23:48             ` Yu Dai
2015-06-24 10:02               ` Daniel Vetter
2015-06-15 18:36 ` [PATCH 13/15] drm/i915: Integrate GuC-based command submission Dave Gordon
2015-06-16  9:22   ` Chris Wilson
2015-06-19 18:18     ` Dave Gordon
2015-06-15 18:36 ` [PATCH 14/15] drm/i915: Debugfs interface for GuC submission statistics Dave Gordon
2015-06-16  9:28   ` Chris Wilson
2015-06-24  8:27     ` Dave Gordon
2015-06-15 18:36 ` [PATCH 15/15] Documentation/drm: kerneldoc for GuC Dave Gordon
2015-06-15 18:36 ` [PATCH 16/15] drm/i915: Enable GuC submission, where supported Dave Gordon
2015-06-17 12:43 ` [PATCH 00/15] Batch submission via GuC Daniel Vetter
2015-06-25  7:23   ` Dave Gordon
2015-06-25  8:05     ` Chris Wilson
2015-06-24 12:16 ` Daniel Vetter
2015-06-24 12:57   ` Chris Wilson
  -- strict thread matches above, loose matches on Subject: below --
2015-07-03 12:30 [PATCH 00/15 v3] " Dave Gordon
2015-07-03 12:30 ` [PATCH 06/15] drm/i915: Debugfs interface to read GuC load status Dave Gordon

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=5583C9A0.1040405@intel.com \
    --to=david.s.gordon@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --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.