public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Kamble, Sagar A" <sagar.a.kamble@intel.com>
To: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chheda Harsh J <harsh.j.chheda@intel.com>,
	intel-gfx@lists.freedesktop.org,
	Fry Gregory P <gregory.p.fry@intel.com>
Subject: Re: [PATCH 5/6] drm/i915/guc: Enable default/critical logging in GuC by default from GuC v9
Date: Tue, 12 Sep 2017 10:09:20 +0530	[thread overview]
Message-ID: <7314ecde-b14a-9cc7-45ae-7eb1ffa0acbd@intel.com> (raw)
In-Reply-To: <20170911180410.GB11504@mwajdecz-MOBL1.ger.corp.intel.com>



On 9/11/2017 11:34 PM, Michal Wajdeczko wrote:
> On Mon, Sep 11, 2017 at 11:32:23AM +0530, Sagar Arun Kamble wrote:
>> From: "Kamble, Sagar A" <sagar.a.kamble@intel.com>
>>
>> With GuC v9, new type of Default/critical logging in GuC to enable
>> capturing minimal important logs in production systems efficiently.
>> This patch enables this logging in GuC by default always. It should
>> be noted that streaming support with half-full interrupt mechanism
>> that is present for normal logging is not present for this type of
>> logging.
>>
>> v2: Emulating GuC critical logging through i915.guc_log_level. Setting
>> this to 0 will make GuC critical logging ON and setting it to 1-4 will
>> communicate log level of 0-3 to GuC.
>>
>> v3: Commit message update. Enable default/critical logging in GuC always.
>> Fixed RPM wake during guc_log_unregister in the unload path.
>>
>> v4: Moved RPM wake change to separate patch. Removed GUC_DEBUG_RESERVED
>> and updated name of new bit to be version agnostic. Updated parameter to
>> struct intel_guc * and name of macro NEEDS_GUC_CRITICAL_LOGGING.
>> Removed explicit clearing of GUC_CRITICAL_LOGGING_DISABLED from
>> params[GUC_CTL_DEBUG] as it is unnecessary. (Michal Wajdeczko)
>>
>> Cc: Chheda Harsh J <harsh.j.chheda@intel.com>
>> Cc: Fry Gregory P <gregory.p.fry@intel.com>
>> Cc: Spotswood John A <john.a.spotswood@intel.com>
>> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
>> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Cc: Michał Winiarski <michal.winiarski@intel.com>
>> Signed-off-by: Jeff McGee <jeff.mcgee@intel.com>
>> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
>> ---
>>   drivers/gpu/drm/i915/intel_guc_fwif.h | 15 +++++++++++++--
>>   drivers/gpu/drm/i915/intel_guc_log.c  |  4 +++-
>>   2 files changed, 16 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h b/drivers/gpu/drm/i915/intel_guc_fwif.h
>> index 5fa2860..3ef228b 100644
>> --- a/drivers/gpu/drm/i915/intel_guc_fwif.h
>> +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
>> @@ -131,7 +131,7 @@
>>   #define   GUC_PROFILE_ENABLED		(1 << 7)
>>   #define   GUC_WQ_TRACK_ENABLED		(1 << 8)
>>   #define   GUC_ADS_ENABLED		(1 << 9)
>> -#define   GUC_DEBUG_RESERVED		(1 << 10)
>> +#define   GUC_CRITICAL_LOGGING_DISABLED	(1 << 10)
> Looks like we don't need this at all
I had disabled this logging in the initial version of patch to reduce 
the impact.
So earlier I had to explicitly declare this bit and set in the 
guc_params[CTL_DEBUG].
But recommendation from GuC team is to keep this always enabled hence we 
can do away with not touching
guc_params[CTL_DEBUG] at all but then in order to make the users aware 
that bit 10 being unset has some meaning I was
clearing it explicitly. Wont removing this bit definition now eliminate 
the meaning for bit 10 while loading GuC all together?

>
>
>>   #define   GUC_ADS_ADDR_SHIFT		11
>>   #define   GUC_ADS_ADDR_MASK		0xfffff800
>>   
>> @@ -139,6 +139,16 @@
>>   
>>   #define GUC_CTL_MAX_DWORDS		(SOFT_SCRATCH_COUNT - 2) /* [1..14] */
>>   
>> +/*
>> + * Critical logging in GuC is to be enabled always from GuC v9+.
>> + * (for KBL - v9.39+)
>> + */
>> +#define GUC_NEEDS_CRITICAL_LOGGING(guc)	\
>> +	(((IS_SKYLAKE(guc_to_i915(guc)) || IS_BROXTON(guc_to_i915(guc))) && \
> Can we use here HAS_GUC() ? Comment says that this is for all Guc
>
> Michal
Yes. Will add this.
>
>
>> +				    guc->fw.major_ver_found >= 9) || \
>> +	  (IS_KABYLAKE(guc_to_i915(guc)) && guc->fw.major_ver_found >= 9 && \
>> +				    guc->fw.minor_ver_found >= 39))
>> +
>>   /**
>>    * DOC: GuC Firmware Layout
>>    *
>> @@ -539,7 +549,8 @@ struct guc_log_buffer_state {
>>   		u32 logging_enabled:1;
>>   		u32 reserved1:3;
>>   		u32 verbosity:4;
>> -		u32 reserved2:24;
>> +		u32 critical_logging_enabled:1;
>> +		u32 reserved2:23;
>>   	};
>>   	u32 value;
>>   } __packed;
>> diff --git a/drivers/gpu/drm/i915/intel_guc_log.c b/drivers/gpu/drm/i915/intel_guc_log.c
>> index 16d3b87..ba36162 100644
>> --- a/drivers/gpu/drm/i915/intel_guc_log.c
>> +++ b/drivers/gpu/drm/i915/intel_guc_log.c
>> @@ -589,7 +589,6 @@ void intel_guc_log_destroy(struct intel_guc *guc)
>>   int i915_guc_log_control(struct drm_i915_private *dev_priv, u64 control_val)
>>   {
>>   	struct intel_guc *guc = &dev_priv->guc;
>> -
>>   	union guc_log_control log_param;
>>   	int ret;
>>   
>> @@ -603,6 +602,9 @@ int i915_guc_log_control(struct drm_i915_private *dev_priv, u64 control_val)
>>   	if (!log_param.logging_enabled && (i915.guc_log_level < 0))
>>   		return 0;
>>   
>> +	if (GUC_NEEDS_CRITICAL_LOGGING(guc))
>> +		log_param.critical_logging_enabled = 1;
>> +
>>   	ret = guc_log_control(guc, log_param.value);
>>   	if (ret < 0) {
>>   		DRM_DEBUG_DRIVER("guc_logging_control action failed %d\n", ret);
>> -- 
>> 1.9.1
>>

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

  reply	other threads:[~2017-09-12  4:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-11  6:02 [PATCH 1/6] drm/i915: Separate GuC/HuC specific functionality from intel_uc Sagar Arun Kamble
2017-09-11  6:02 ` [PATCH 2/6] drm/i915/guc: Make guc_enable/disable_communication functions public Sagar Arun Kamble
2017-09-11  6:02 ` [PATCH 3/6] drm/i915/guc: Fix GuC interaction in reset/suspend scenarios Sagar Arun Kamble
2017-09-11  6:02 ` [PATCH 4/6] drm/i915/guc: Fix GuC HW/SW state cleanup in unload path Sagar Arun Kamble
2017-09-11  6:02 ` [PATCH 5/6] drm/i915/guc: Enable default/critical logging in GuC by default from GuC v9 Sagar Arun Kamble
2017-09-11 18:04   ` Michal Wajdeczko
2017-09-12  4:39     ` Kamble, Sagar A [this message]
2017-09-11  6:02 ` [PATCH 6/6] drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts Sagar Arun Kamble
2017-09-11 17:34   ` Michal Wajdeczko
2017-09-12  4:33     ` Kamble, Sagar A
2017-09-11  6:19 ` ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915: Separate GuC/HuC specific functionality from intel_uc Patchwork
2017-09-11  7:18 ` ✗ Fi.CI.IGT: failure " Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2017-09-13  6:30 [PATCH 1/6] " Sagar Arun Kamble
2017-09-13  6:30 ` [PATCH 5/6] drm/i915/guc: Enable default/critical logging in GuC by default from GuC v9 Sagar Arun Kamble
2017-09-14  9:55 [PATCH 0/6] GuC code restructuring and fixes Sagar Arun Kamble
2017-09-14  9:55 ` [PATCH 5/6] drm/i915/guc: Enable default/critical logging in GuC by default from GuC v9 Sagar Arun Kamble
2017-09-14 13:13   ` Michal Wajdeczko
2017-09-14 16:00     ` Kamble, Sagar A

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=7314ecde-b14a-9cc7-45ae-7eb1ffa0acbd@intel.com \
    --to=sagar.a.kamble@intel.com \
    --cc=gregory.p.fry@intel.com \
    --cc=harsh.j.chheda@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