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
next prev parent 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