public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Anusha Srivatsa <anusha.srivatsa@intel.com>
To: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/i915/guc: Add GuC Load time to dmesg log.
Date: Thu, 2 Nov 2017 11:04:04 -0700	[thread overview]
Message-ID: <20171102180404.GB6940@intel.com> (raw)
In-Reply-To: <op.y800ejgyxaggs7@mwajdecz-mobl1.ger.corp.intel.com>

On Wed, Nov 01, 2017 at 02:14:33PM +0100, Michal Wajdeczko wrote:
> On Wed, 01 Nov 2017 01:11:20 +0100, Anusha Srivatsa
> <anusha.srivatsa@intel.com> wrote:
> 
> >Calculate the time that GuC takes to load using
> >jiffies. This information could be very useful in
>   ^^^^^^^
> This is no longer true.

True. Will sending an all new patch with updated 
approach(using ktime instead of jiffies) be good?
Or stick to this with change in commit message?

> >determining if GuC is taking unreasonably long time
> >to load in a certain platforms.
> >
> >v2: Calculate time before logs are collected.
> >Move the guc_load_time variable as a part of
> >intel_uc_fw struct. Store only final result
> >which is to be exported to debugfs. (Michal)
> >Add the load time in the print message as well.
> >
> >v3: Remove debugfs entry. Remove local variable
> >guc_finish_load. (Daniel, Tvrtko)
> >
> >v4: Use ktime_get() instead of jiffies. Use DRM_NOTE
> >if time taken to load is more than the threshold. On
> >load times within acceptable range, use DRM_DEBUG_DRIVER
> >(Tvrtko)
> >
> >v5: Rebased. Do not expose the load time variable in a global
> >struct (Tvrtko, Joonas)
> >
> >Cc: Chris Wilson <chris@chris-wilson.co.uk>
> >Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> >Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> >Cc: Oscar Mateo <oscar.mateo@intel.com>
> >Cc: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com>
> >Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> >Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
> >---
> > drivers/gpu/drm/i915/intel_guc_fw.c | 11 +++++++++--
> > 1 file changed, 9 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c
> >b/drivers/gpu/drm/i915/intel_guc_fw.c
> >index ef67a36..4ce9a30 100644
> >--- a/drivers/gpu/drm/i915/intel_guc_fw.c
> >+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
> >@@ -133,7 +133,8 @@ static int guc_ucode_xfer_dma(struct drm_i915_private
> >*dev_priv,
> > 	unsigned long offset;
> > 	struct sg_table *sg = vma->pages;
> > 	u32 status, rsa[UOS_RSA_SCRATCH_MAX_COUNT];
> >-	int i, ret = 0;
> >+	int i, ret = 0, load_time;
> 
> Note that ktime_ms_delta() return type is s64 not int.
> 
> >+	ktime_t start_load;
> 
> s/start_load/now ?

I think start_load is verbose. 
 
> >	/* where RSA signature starts */
> > 	offset = guc_fw->rsa_offset;
> >@@ -160,6 +161,7 @@ static int guc_ucode_xfer_dma(struct drm_i915_private
> >*dev_priv,
> > 	I915_WRITE(DMA_ADDR_1_HIGH, DMA_ADDRESS_SPACE_WOPCM);
> >	/* Finally start the DMA */
> >+	start_load = ktime_get();
> 
> Maybe we should either update comment with note about taking start time
> or move ktime_get call before that comment to avoid confusion..

I prefer the latter.
 
> > 	I915_WRITE(DMA_CTRL, _MASKED_BIT_ENABLE(UOS_MOVE | START_DMA));
> >	/*
> >@@ -172,13 +174,18 @@ static int guc_ucode_xfer_dma(struct
> >drm_i915_private *dev_priv,
> > 	 */
> > 	ret = wait_for(guc_ucode_response(dev_priv, &status), 100);
> >+	load_time = ktime_ms_delta(ktime_get(), start_load);
> >+
> > 	DRM_DEBUG_DRIVER("DMA status 0x%x, GuC status 0x%x\n",
> > 			I915_READ(DMA_CTRL), status);
> >	if ((status & GS_BOOTROM_MASK) == GS_BOOTROM_RSA_FAILED) {
> > 		DRM_ERROR("GuC firmware signature verification failed\n");
> > 		ret = -ENOEXEC;
> >-	}
> >+	} else if (load_time > 20)
> >+		DRM_NOTE("GuC load takes more than acceptable threshold\n");
> 
> Please add threshold and actual load time to the message to let user
> know that times
 
> >+	else
> >+		DRM_DEBUG_DRIVER("GuC loaded in %d ms\n", load_time);
> 
> And I'm not sure that we can rely on 'load_time' on timeout in wait_for.

Hmm.... we  are checking the DMA status right after that which means
the firmware load should have happened by then.... thats why I 
am calculating it there....

 
> >	DRM_DEBUG_DRIVER("returning %d\n", ret);

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

  parent reply	other threads:[~2017-11-02 18:06 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-01  0:11 [PATCH 1/2] drm/i915/guc: Add GuC Load time to dmesg log Anusha Srivatsa
2017-11-01  0:11 ` [PATCH 2/2] drm/i915/huc: Add HuC " Anusha Srivatsa
2017-11-01 13:32   ` Michal Wajdeczko
2017-11-01  1:07 ` ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/guc: Add GuC " Patchwork
2017-11-01  1:50 ` ✓ Fi.CI.IGT: " Patchwork
2017-11-01 13:14 ` [PATCH 1/2] " Michal Wajdeczko
2017-11-01 13:24   ` Chris Wilson
2017-11-02 20:28     ` Anusha Srivatsa
2017-11-02 20:33       ` Chris Wilson
2017-11-02 18:04   ` Anusha Srivatsa [this message]
2017-11-01 13:38 ` David Weinehall
2017-11-01 13:48   ` Chris Wilson
  -- strict thread matches above, loose matches on Subject: below --
2017-10-04  0:41 Anusha Srivatsa
2017-10-04  8:16 ` Tvrtko Ursulin
2017-10-04 12:51   ` Joonas Lahtinen
2017-10-06  0:56     ` Srivatsa, Anusha
2017-10-06  6:29       ` Joonas Lahtinen
2017-10-09 17:24         ` Srivatsa, Anusha
2017-10-06  0:41   ` Srivatsa, Anusha
     [not found] <1505954668-2748-1-git-send-email-anusha.srivatsa@intel.com>
     [not found] ` <9108028B3EB68E4CA5158371AB76E601633C4616@IRSMSX106.ger.corp.intel.com>
2017-09-22 20:12   ` Srivatsa, Anusha
2017-09-25  8:31     ` Tvrtko Ursulin

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=20171102180404.GB6940@intel.com \
    --to=anusha.srivatsa@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=michal.wajdeczko@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox