All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Sagar Arun Kamble <sagar.a.kamble@intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 04/11] drm/i915/guc: Sanitize module parameter guc_log_level
Date: Thu, 19 Oct 2017 08:22:17 +0100	[thread overview]
Message-ID: <2118755e-9747-9e11-df96-ead24e747fd1@linux.intel.com> (raw)
In-Reply-To: <3a51f7a3-0cf8-6312-cf5c-618d50264a60@intel.com>


On 18/10/2017 16:50, Sagar Arun Kamble wrote:
> On 10/18/2017 6:29 PM, Tvrtko Ursulin wrote:
>>
>> On 18/10/2017 07:46, Sagar Arun Kamble wrote:
>>> Parameter guc_log_level needs to be sanitized based on GuC support and
>>> enable_guc_loading parameter since it depends on them like
>>> enable_guc_submission. This will make GuC logging paths independent of
>>> enable_guc_submission parameter in further patches.
>>>
>>> v2: Added documentation to intel_guc_log.c and param description about
>>> GuC loading dependency. (Michal Wajdeczko)
>>>
>>> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
>>> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>>> ---
>>>   drivers/gpu/drm/i915/i915_params.c   |  4 +++-
>>>   drivers/gpu/drm/i915/intel_guc_log.c |  1 +
>>>   drivers/gpu/drm/i915/intel_uc.c      | 10 +++++++---
>>>   3 files changed, 11 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_params.c 
>>> b/drivers/gpu/drm/i915/i915_params.c
>>> index b4faeb6..774c56e 100644
>>> --- a/drivers/gpu/drm/i915/i915_params.c
>>> +++ b/drivers/gpu/drm/i915/i915_params.c
>>> @@ -171,7 +171,9 @@ struct i915_params i915_modparams __read_mostly = {
>>>       "(-1=auto, 0=never [default], 1=if available, 2=required)");
>>>     i915_param_named(guc_log_level, int, 0400,
>>> -    "GuC firmware logging level (-1:disabled (default), 0-3:enabled)");
>>> +    "GuC firmware logging level. This takes effect only if GuC is to 
>>> be "
>>> +    "loaded (depends on enable_guc_loading) (-1:disabled (default), "
>>> +    "0-3:enabled)");
>>>     i915_param_named_unsafe(guc_firmware_path, charp, 0400,
>>>       "GuC firmware path to use instead of the default one");
>>> diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
>>> b/drivers/gpu/drm/i915/intel_guc_log.c
>>> index f53c663..200f0a1 100644
>>> --- a/drivers/gpu/drm/i915/intel_guc_log.c
>>> +++ b/drivers/gpu/drm/i915/intel_guc_log.c
>>> @@ -34,6 +34,7 @@
>>>    * DOC: GuC firmware log
>>>    *
>>>    * Firmware log is enabled by setting i915.guc_log_level to 
>>> non-negative level.
>>> + * This takes effect only if GuC is to be loaded based on 
>>> enable_guc_loading.
>>>    * Log data is printed out via reading debugfs i915_guc_log_dump. 
>>> Reading from
>>>    * i915_guc_load_status will print out firmware loading status and 
>>> scratch
>>>    * registers value.
>>> diff --git a/drivers/gpu/drm/i915/intel_uc.c 
>>> b/drivers/gpu/drm/i915/intel_uc.c
>>> index 62738ad..8feefcd 100644
>>> --- a/drivers/gpu/drm/i915/intel_uc.c
>>> +++ b/drivers/gpu/drm/i915/intel_uc.c
>>> @@ -51,11 +51,13 @@ void intel_uc_sanitize_options(struct 
>>> drm_i915_private *dev_priv)
>>>   {
>>>       if (!HAS_GUC(dev_priv)) {
>>>           if (i915_modparams.enable_guc_loading > 0 ||
>>> -            i915_modparams.enable_guc_submission > 0)
>>> +            i915_modparams.enable_guc_submission > 0 ||
>>> +            i915_modparams.guc_log_level > 0)
>>>               DRM_INFO("Ignoring GuC options, no hardware\n");
>>
>> Hm, this won't fire on <=gen8 once enable_guc_submission starts to 
>> default to one? Or we can worry about that when we get there...
> This will fire for <=gen8 for +ve values which is expected.
>>
>>> i915_modparams.enable_guc_loading = 0;
>>>           i915_modparams.enable_guc_submission = 0;
>>> +        i915_modparams.guc_log_level = -1;
>>>           return;
>>>       }
>>>   @@ -72,9 +74,11 @@ void intel_uc_sanitize_options(struct 
>>> drm_i915_private *dev_priv)
>>>               i915_modparams.enable_guc_loading = 0;
>>>       }
>>>   -    /* Can't enable guc submission without guc loaded */
>>> -    if (!i915_modparams.enable_guc_loading)
>>> +    /* Can't enable guc submission and logging without guc loaded */
>>> +    if (!i915_modparams.enable_guc_loading) {
>>>           i915_modparams.enable_guc_submission = 0;
>>> +        i915_modparams.guc_log_level = -1;
>>
>> Hm2, how does this interact with the changes which are removing 
>> enable_guc_loading? Or it is a race?
> It interacts. Will race. I think I should pause this series till the 
> other one gets merged.

Okay, it's your call (as in you guys who are refactoring GuC heavily at 
the moment).

Should I continue to the end of this one then? It is not that big so I 
just as well can.

Regards,

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

  reply	other threads:[~2017-10-19  7:22 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-18  6:46 [PATCH 00/11] GuC Interrupts/Log updates Sagar Arun Kamble
2017-10-18  6:46 ` [PATCH 01/11] drm/i915: Export low level PM IRQ functions to control from GuC functions Sagar Arun Kamble
2017-10-18 12:42   ` Tvrtko Ursulin
2017-10-18 13:48     ` Sagar Arun Kamble
2017-10-18  6:46 ` [PATCH 02/11] drm/i915/guc: Move GuC interrupts related functions from i915_irq.c to intel_guc.c Sagar Arun Kamble
2017-10-18 12:46   ` Tvrtko Ursulin
2017-10-18 14:06     ` Sagar Arun Kamble
2017-10-18  6:46 ` [PATCH 03/11] drm/i915/guc: Pass intel_guc struct parameter to GuC interrupts functions Sagar Arun Kamble
2017-10-18 12:47   ` Tvrtko Ursulin
2017-10-18  6:46 ` [PATCH 04/11] drm/i915/guc: Sanitize module parameter guc_log_level Sagar Arun Kamble
2017-10-18 12:59   ` Tvrtko Ursulin
2017-10-18 15:50     ` Sagar Arun Kamble
2017-10-19  7:22       ` Tvrtko Ursulin [this message]
2017-10-21  8:11         ` Sagar Arun Kamble
2017-10-18  6:46 ` [PATCH 05/11] drm/i915/guc: Make GuC log related functions depend only on log level Sagar Arun Kamble
2017-10-18 13:07   ` Tvrtko Ursulin
2017-10-18 15:57     ` Sagar Arun Kamble
2017-10-18  6:46 ` [PATCH 06/11] drm/i915/guc: Only release GuC log object during submission_fini Sagar Arun Kamble
2017-10-18 13:12   ` Tvrtko Ursulin
2017-10-18 16:04     ` Sagar Arun Kamble
2017-10-19  7:18       ` Tvrtko Ursulin
2017-10-21  8:09         ` Sagar Arun Kamble
2017-10-18  6:46 ` [PATCH 07/11] drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts Sagar Arun Kamble
2017-10-19 10:09   ` Tvrtko Ursulin
2017-10-21 13:27     ` Sagar Arun Kamble
2017-10-18  6:46 ` [PATCH 08/11] drm/i915/guc: Add client support to enable/disable " Sagar Arun Kamble
2017-10-19 10:19   ` Tvrtko Ursulin
2017-10-21 16:38     ` Sagar Arun Kamble
2017-10-18  6:47 ` [PATCH 09/11] drm/i915/guc: Fix GuC interrupts disabling with Logging Sagar Arun Kamble
2017-10-19 10:24   ` Tvrtko Ursulin
2017-10-21 16:39     ` Sagar Arun Kamble
2017-10-18  6:47 ` [PATCH 10/11] drm/i915/guc: Skip interrupt enabling if logging is already enabled Sagar Arun Kamble
2017-10-19 10:31   ` Tvrtko Ursulin
2017-10-21 16:47     ` Sagar Arun Kamble
2017-10-18  6:47 ` [PATCH 11/11] drm/i915/guc: Restore GuC interrupts across suspend/reset if enabled Sagar Arun Kamble
2017-10-19 11:03   ` Tvrtko Ursulin
2017-10-21 17:09     ` Sagar Arun Kamble
2017-10-18  7:02 ` ✓ Fi.CI.BAT: success for GuC Interrupts/Log updates Patchwork
2017-10-18 13:41 ` ✓ Fi.CI.IGT: " 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=2118755e-9747-9e11-df96-ead24e747fd1@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=sagar.a.kamble@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.