Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Gustavo Sousa <gustavo.sousa@intel.com>,
	intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Cc: lucas.demarchi@intel.com, rodrigo.vivi@intel.com
Subject: Re: [PATCH 2/5] drm/i915/dmc: improve firmware parse failure propagation
Date: Thu, 18 Apr 2024 23:03:22 +0300	[thread overview]
Message-ID: <87il0ewi9h.fsf@intel.com> (raw)
In-Reply-To: <171346641545.2007.10117149787974036842@gjsousa-mobl2>

On Thu, 18 Apr 2024, Gustavo Sousa <gustavo.sousa@intel.com> wrote:
> Quoting Jani Nikula (2024-04-18 11:39:51-03:00)
>>Return failures from parse_dmc_fw() instead of relying on
>>intel_dmc_has_payload(). Handle and error report them slightly better.
>>
>>Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>>---
>> drivers/gpu/drm/i915/display/intel_dmc.c | 39 +++++++++++++-----------
>> 1 file changed, 22 insertions(+), 17 deletions(-)
>>
>>diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c b/drivers/gpu/drm/i915/display/intel_dmc.c
>>index 65880dea9c15..ee5db1aafd50 100644
>>--- a/drivers/gpu/drm/i915/display/intel_dmc.c
>>+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
>>@@ -853,7 +853,7 @@ static u32 parse_dmc_fw_css(struct intel_dmc *dmc,
>>         return sizeof(struct intel_css_header);
>> }
>> 
>>-static void parse_dmc_fw(struct intel_dmc *dmc, const struct firmware *fw)
>>+static int parse_dmc_fw(struct intel_dmc *dmc, const struct firmware *fw)
>> {
>>         struct drm_i915_private *i915 = dmc->i915;
>>         struct intel_css_header *css_header;
>>@@ -866,13 +866,13 @@ static void parse_dmc_fw(struct intel_dmc *dmc, const struct firmware *fw)
>>         u32 r, offset;
>> 
>>         if (!fw)
>>-                return;
>>+                return -EINVAL;
>> 
>>         /* Extract CSS Header information */
>>         css_header = (struct intel_css_header *)fw->data;
>>         r = parse_dmc_fw_css(dmc, css_header, fw->size);
>>         if (!r)
>>-                return;
>>+                return -EINVAL;
>> 
>>         readcount += r;
>> 
>>@@ -880,7 +880,7 @@ static void parse_dmc_fw(struct intel_dmc *dmc, const struct firmware *fw)
>>         package_header = (struct intel_package_header *)&fw->data[readcount];
>>         r = parse_dmc_fw_package(dmc, package_header, si, fw->size - readcount);
>>         if (!r)
>>-                return;
>>+                return -EINVAL;
>> 
>>         readcount += r;
>> 
>>@@ -897,6 +897,11 @@ static void parse_dmc_fw(struct intel_dmc *dmc, const struct firmware *fw)
>>                 dmc_header = (struct intel_dmc_header_base *)&fw->data[offset];
>>                 parse_dmc_fw_header(dmc, dmc_header, fw->size - offset, dmc_id);
>>         }
>>+
>>+        if (!intel_dmc_has_payload(i915))
>>+                return -ENOENT;
>
> This function and also the parsing helpers (parse_dmc_fw_*) already have
> the pattern of providing error messages for issues found. We could maybe
> have parse_dmc_fw() simply returning -1 for errors here.

I've become increasingly opposed to the magic -1 error return in the
kernel. Basically all negative error codes have a meaning, and -1 is
-EPERM. (I even have a branch converting a bunch of "return -1" to
something more meaningful.)

But I guess -1 wasn't really the main point about your comment anyway.

> For this specific condition (!intel_dmc_has_payload(i915)), we could
> complain that there the main DMC program was not found before returning.

Agreed.

> I think ENOENT might confuse users.

So would you rather just skip printing the error code returned by
parse_dmc_fw()? I take it this was really the main point?

BR,
Jani.


>
> --
> Gustavo Sousa
>
>>+
>>+        return 0;
>> }
>> 
>> static void intel_dmc_runtime_pm_get(struct drm_i915_private *i915)
>>@@ -951,22 +956,22 @@ static void dmc_load_work_fn(struct work_struct *work)
>>                 return;
>>         }
>> 
>>-        parse_dmc_fw(dmc, fw);
>>-
>>-        if (intel_dmc_has_payload(i915)) {
>>-                intel_dmc_load_program(i915);
>>-                intel_dmc_runtime_pm_put(i915);
>>-
>>-                drm_info(&i915->drm, "Finished loading DMC firmware %s (v%u.%u)\n",
>>-                         dmc->fw_path, DMC_VERSION_MAJOR(dmc->version),
>>-                         DMC_VERSION_MINOR(dmc->version));
>>-        } else {
>>+        err = parse_dmc_fw(dmc, fw);
>>+        if (err) {
>>                 drm_notice(&i915->drm,
>>-                           "Failed to load DMC firmware %s."
>>-                           " Disabling runtime power management.\n",
>>-                           dmc->fw_path);
>>+                           "Failed to parse DMC firmware %s (%pe). Disabling runtime power management.\n",
>>+                           dmc->fw_path, ERR_PTR(err));
>>+                goto out;
>>         }
>> 
>>+        intel_dmc_load_program(i915);
>>+        intel_dmc_runtime_pm_put(i915);
>>+
>>+        drm_info(&i915->drm, "Finished loading DMC firmware %s (v%u.%u)\n",
>>+                 dmc->fw_path, DMC_VERSION_MAJOR(dmc->version),
>>+                 DMC_VERSION_MINOR(dmc->version));
>>+
>>+out:
>>         release_firmware(fw);
>> }
>> 
>>-- 
>>2.39.2
>>

-- 
Jani Nikula, Intel

  reply	other threads:[~2024-04-18 20:03 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-18 14:39 [PATCH 0/5] drm/i915/dmc: firmware path handling changes Jani Nikula
2024-04-18 14:39 ` [PATCH 1/5] drm/i915/dmc: handle request_firmware() errors separately Jani Nikula
2024-04-18 18:30   ` Gustavo Sousa
2024-04-18 19:56     ` Jani Nikula
2024-04-18 19:59       ` Gustavo Sousa
2024-04-18 14:39 ` [PATCH 2/5] drm/i915/dmc: improve firmware parse failure propagation Jani Nikula
2024-04-18 18:53   ` Gustavo Sousa
2024-04-18 20:03     ` Jani Nikula [this message]
2024-04-18 20:40       ` Gustavo Sousa
2024-04-18 14:39 ` [PATCH 3/5] drm/i915/dmc: split out per-platform firmware path selection Jani Nikula
2024-04-18 19:00   ` Gustavo Sousa
2024-04-18 14:39 ` [PATCH 4/5] drm/i915/dmc: change meaning of dmc_firmware_path="" module param Jani Nikula
2024-04-18 19:19   ` Gustavo Sousa
2024-04-18 20:09     ` Jani Nikula
2024-04-18 20:44       ` Gustavo Sousa
2024-04-18 20:49         ` Lucas De Marchi
2024-04-18 14:39 ` [PATCH 5/5] drm/i915/display: move dmc_firmware_path to display params Jani Nikula
2024-04-18 19:43   ` Gustavo Sousa
2024-04-18 16:54 ` ✓ CI.Patch_applied: success for drm/i915/dmc: firmware path handling changes Patchwork
2024-04-18 16:54 ` ✗ CI.checkpatch: warning " Patchwork
2024-04-18 16:55 ` ✓ CI.KUnit: success " Patchwork
2024-04-18 17:15 ` ✓ CI.Build: " Patchwork
2024-04-18 17:17 ` ✓ CI.Hooks: " Patchwork
2024-04-18 17:25 ` ✗ CI.checksparse: warning " Patchwork
2024-04-18 18:01 ` ✓ CI.BAT: success " Patchwork
2024-04-20  8:00 ` ✗ CI.FULL: failure " 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=87il0ewi9h.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=gustavo.sousa@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=rodrigo.vivi@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