From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Dave Gordon <david.s.gordon@intel.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [CI-RESEND 3/3] drm/i915/guc: revisit GuC loader message levels
Date: Tue, 19 Jul 2016 15:26:16 +0100 [thread overview]
Message-ID: <578E3888.8020908@linux.intel.com> (raw)
In-Reply-To: <1468930818-22085-3-git-send-email-david.s.gordon@intel.com>
On 19/07/16 13:20, Dave Gordon wrote:
> Some downgraded from DRM_ERROR() to DRM_WARN() or DRM_NOTE(),
> a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(),
> and one eliminated completely.
>
> v2: different permutation of levels :)
>
> Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
> ---
> drivers/gpu/drm/i915/intel_guc_loader.c | 34 ++++++++++++++++-----------------
> 1 file changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c b/drivers/gpu/drm/i915/intel_guc_loader.c
> index 605c696..a2f4fa4 100644
> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> @@ -140,12 +140,14 @@ static u32 get_gttype(struct drm_i915_private *dev_priv)
>
> static u32 get_core_family(struct drm_i915_private *dev_priv)
> {
> - switch (INTEL_INFO(dev_priv)->gen) {
> + u32 gen = INTEL_GEN(dev_priv);
> +
> + switch (gen) {
> case 9:
> return GFXCORE_FAMILY_GEN9;
>
> default:
> - DRM_ERROR("GUC: unsupported core family\n");
> + DRM_WARN("GEN%d does not support GuC operation\n", gen);
This looks more like a WARN_ON condition to me, something developers
need to notice extremely easily in development and will never happen in
deployment.
> return GFXCORE_FAMILY_UNKNOWN;
> }
> }
> @@ -433,7 +435,7 @@ int intel_guc_setup(struct drm_device *dev)
> goto fail;
> } else if (*fw_path == '\0') {
> /* Device has a GuC but we don't know what f/w to load? */
> - DRM_INFO("No GuC firmware known for this platform\n");
> + DRM_WARN("No GuC firmware known for this platform\n");
This looks the same to me (WARN_ON), it can only happen if someone
messes up things in development.
> err = -ENODEV;
> goto fail;
> }
> @@ -471,10 +473,8 @@ int intel_guc_setup(struct drm_device *dev)
> * that the state and timing are fairly predictable
> */
> err = i915_reset_guc(dev_priv);
> - if (err) {
> - DRM_ERROR("GuC reset failed: %d\n", err);
> + if (err)
> goto fail;
> - }
>
> err = guc_ucode_xfer(dev_priv);
> if (!err)
> @@ -532,15 +532,15 @@ int intel_guc_setup(struct drm_device *dev)
> else if (err == 0)
> DRM_INFO("GuC firmware load skipped\n");
> else if (ret != -EIO)
> - DRM_INFO("GuC firmware load failed: %d\n", err);
> + DRM_NOTE("GuC firmware load failed: %d\n", err);
> else
> - DRM_ERROR("GuC firmware load failed: %d\n", err);
> + DRM_WARN("GuC firmware load failed: %d\n", err);
>
> if (i915.enable_guc_submission) {
> if (fw_path == NULL)
> DRM_INFO("GuC submission without firmware not supported\n");
> if (ret == 0)
> - DRM_INFO("Falling back from GuC submission to execlist mode\n");
> + DRM_NOTE("Falling back from GuC submission to execlist mode\n");
> else
> DRM_ERROR("GuC init failed: %d\n", ret);
> }
> @@ -571,7 +571,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct intel_guc_fw *guc_fw)
>
> /* Check the size of the blob before examining buffer contents */
> if (fw->size < sizeof(struct guc_css_header)) {
> - DRM_ERROR("Firmware header is missing\n");
> + DRM_NOTE("Firmware header is missing\n");
> goto fail;
> }
>
> @@ -583,7 +583,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct intel_guc_fw *guc_fw)
> css->key_size_dw - css->exponent_size_dw) * sizeof(u32);
>
> if (guc_fw->header_size != sizeof(struct guc_css_header)) {
> - DRM_ERROR("CSS header definition mismatch\n");
> + DRM_NOTE("CSS header definition mismatch\n");
> goto fail;
> }
>
> @@ -593,7 +593,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct intel_guc_fw *guc_fw)
>
> /* now RSA */
> if (css->key_size_dw != UOS_RSA_SCRATCH_MAX_COUNT) {
> - DRM_ERROR("RSA key size is bad\n");
> + DRM_NOTE("RSA key size is bad\n");
> goto fail;
> }
> guc_fw->rsa_offset = guc_fw->ucode_offset + guc_fw->ucode_size;
> @@ -602,14 +602,14 @@ static void guc_fw_fetch(struct drm_device *dev, struct intel_guc_fw *guc_fw)
> /* At least, it should have header, uCode and RSA. Size of all three. */
> size = guc_fw->header_size + guc_fw->ucode_size + guc_fw->rsa_size;
> if (fw->size < size) {
> - DRM_ERROR("Missing firmware components\n");
> + DRM_NOTE("Missing firmware components\n");
> goto fail;
> }
>
> /* Header and uCode will be loaded to WOPCM. Size of the two. */
> size = guc_fw->header_size + guc_fw->ucode_size;
> if (size > guc_wopcm_size(to_i915(dev))) {
> - DRM_ERROR("Firmware is too large to fit in WOPCM\n");
> + DRM_NOTE("Firmware is too large to fit in WOPCM\n");
> goto fail;
> }
>
> @@ -624,7 +624,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct intel_guc_fw *guc_fw)
>
> if (guc_fw->guc_fw_major_found != guc_fw->guc_fw_major_wanted ||
> guc_fw->guc_fw_minor_found < guc_fw->guc_fw_minor_wanted) {
> - DRM_ERROR("GuC firmware version %d.%d, required %d.%d\n",
> + DRM_NOTE("GuC firmware version %d.%d, required %d.%d\n",
> guc_fw->guc_fw_major_found, guc_fw->guc_fw_minor_found,
> guc_fw->guc_fw_major_wanted, guc_fw->guc_fw_minor_wanted);
> err = -ENOEXEC;
> @@ -654,10 +654,10 @@ static void guc_fw_fetch(struct drm_device *dev, struct intel_guc_fw *guc_fw)
> return;
>
> fail:
> + DRM_WARN("Failed to fetch valid GuC firmware from %s (error %d)\n",
> + guc_fw->guc_fw_path, err);
> DRM_DEBUG_DRIVER("GuC fw fetch status FAIL; err %d, fw %p, obj %p\n",
> err, fw, guc_fw->guc_fw_obj);
As commented before, I would tidy these two into one while dropping the
uninteresting debug like object pointe and fw name pointer.
> - DRM_ERROR("Failed to fetch GuC firmware from %s (error %d)\n",
> - guc_fw->guc_fw_path, err);
>
> mutex_lock(&dev->struct_mutex);
> obj = guc_fw->guc_fw_obj;
>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Also, you can keep it if you decide to act on my suggestions from above.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-07-19 14:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-19 12:20 [CI-RESEND 1/3] drm: extra printk() wrapper macros Dave Gordon
2016-07-19 12:20 ` [CI-RESEND 2/3] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN() Dave Gordon
2016-07-19 14:16 ` Tvrtko Ursulin
2016-07-19 12:20 ` [CI-RESEND 3/3] drm/i915/guc: revisit GuC loader message levels Dave Gordon
2016-07-19 14:26 ` Tvrtko Ursulin [this message]
2016-07-19 16:03 ` Dave Gordon
2016-07-19 13:53 ` ✓ Ro.CI.BAT: success for series starting with [CI-RESEND,1/3] drm: extra printk() wrapper macros Patchwork
2016-07-19 14:49 ` 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=578E3888.8020908@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=david.s.gordon@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox