From: "Ceraolo Spurio, Daniele" <daniele.ceraolospurio@intel.com>
To: "Teres Alexis, Alan Previn" <alan.previn.teres.alexis@intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>
Cc: "dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"Vivi, Rodrigo" <rodrigo.vivi@intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915/gsc: GSC firmware loading
Date: Wed, 7 Dec 2022 08:46:31 -0800 [thread overview]
Message-ID: <64b04c01-471b-ded6-2bc3-13319f3b01c6@intel.com> (raw)
In-Reply-To: <7fdc90e651313c3238e66b1a5879300c4680cb28.camel@intel.com>
On 12/7/2022 2:16 AM, Teres Alexis, Alan Previn wrote:
> Diffed the patches and reviewed the changes -- i.e. the use of the worker for the gsc fw loading cmd submission.
> All looks good - just a few nits below.
>
> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
>
> On Mon, 2022-12-05 at 21:15 -0800, Ceraolo Spurio, Daniele wrote:
>> GSC FW is loaded by submitting a dedicated command via the GSC engine.
>> The memory area used for loading the FW is then re-purposed as local
>> memory for the GSC itself, so we use a separate allocation instead of
>> using the one where we keep the firmware stored for reload.
>>
>>
>>
> Alan:[snip]
>
>
>> +int intel_gsc_uc_fw_upload(struct intel_gsc_uc *gsc)
>> +{
>> + struct intel_gt *gt = gsc_uc_to_gt(gsc);
>> + struct intel_uc_fw *gsc_fw = &gsc->fw;
>> + int err;
>> +
>> + /* check current fw status */
>> + if (intel_gsc_uc_fw_init_done(gsc)) {
>> + if (GEM_WARN_ON(!intel_uc_fw_is_loaded(gsc_fw)))
>> + intel_uc_fw_change_status(gsc_fw, INTEL_UC_FIRMWARE_TRANSFERRED);
>> + return -EEXIST;
>> + }
>> +
> Alan: Nit: I see you've put the -EEXIST back again - not sure if we need it. I'm marking this as Nit simply because we
> dont consumer the return value from where its being called - but its still weird that we are returning an error in the
> case where FW is already there so we skip loading and allow normal operational flow (not error-ing out).
>
> Alan: Nit: not sure if we should explain in the comments how we can already find the gsc-fw pre-loaded (IIRC, it could
> be a prior driver unload that didn't do the FLR?).
It should be impossible to get here with an already loaded FW, because
we only queue the worker if the FW is not already loaded. However, for
safety I wanted to add in a check to make sure we're covered in case
something weird happens. Note that there is a GEM_WARN_ON tied to
intel_uc_fw_is_loaded(); this is because if that function returns true
it means the driver knows that the FW is already loaded and therefore
the error is just that the worker got called one time too many, while if
that is false it means that we got out of sync with the HW state and
that's a serious bug we want to flag.
Regarding the -EEXIST, that's in preparation for a follow up patch that
adds more functions to the worker (SW proxy) that will have to be
skipped if the GSC is already loaded. As you said it doesn't make a
difference now so I thought to start directly with it instead of
returning zero now and switching later.
>
>> + if (!intel_uc_fw_is_loadable(gsc_fw))
>> + return -ENOEXEC;
>> +
>> + /* FW blob is ok, so clean the status */
>> + intel_uc_fw_sanitize(&gsc->fw);
>> +
>> + if (!gsc_is_in_reset(gt->uncore))
>> + return -EIO;
>> +
>> + err = gsc_fw_load_prepare(gsc);
>> + if (err)
>> + goto fail;
>> +
>> +
> Alan: [snip]
>
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
>> index 65cbf1ce9fa1..3692ba387834 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
>> @@ -7,8 +7,19 @@
>>
>> #include "gt/intel_gt.h"
>> #include "intel_gsc_uc.h"
>> +#include "intel_gsc_fw.h"
> Alan: alphabetical ordering? (not sure if this is a hard rule, for me its a nit)
>
>> #include "i915_drv.h"
>>
>> +static void gsc_work(struct work_struct *work)
> Alan: Nit: would ne nicer to call it gsc_load_worker unless there maybe future plans to expand this worker's scope.
There is, this same worker will handle sw proxy as well.
>> +{
>> + struct intel_gsc_uc *gsc = container_of(work, typeof(*gsc), work);
>> + struct intel_gt *gt = gsc_uc_to_gt(gsc);
>> + intel_wakeref_t wakeref;
>> +
>> + with_intel_runtime_pm(gt->uncore->rpm, wakeref)
>> + intel_gsc_uc_fw_upload(gsc);
>> +}
>> +
> Alan:[snip]
>
>
>> struct intel_gsc_uc {
>> /* Generic uC firmware management */
>> struct intel_uc_fw fw;
>> +
>> + /* GSC-specific additions */
>> + struct i915_vma *local; /* private memory for GSC usage */
>> + struct intel_context *ce; /* for submission to GSC FW via GSC engine */
>> +
>> + struct work_struct work; /* for delayed load */
> Alan: nit: would be nicer to call it "load_worker" unless the future plan is to expand the scope of what else that
> worker could be used for.
same as above.
Daniele
>
> Alan:[snip]
>
>
next prev parent reply other threads:[~2022-12-07 16:46 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-06 1:19 [Intel-gfx] [PATCH v2 0/6] drm/i915: Add support for GSC FW loading Daniele Ceraolo Spurio
2022-12-06 1:19 ` [Intel-gfx] [PATCH v2 1/6] drm/i915/uc: Introduce GSC FW Daniele Ceraolo Spurio
2022-12-08 4:09 ` Teres Alexis, Alan Previn
2022-12-06 1:19 ` [Intel-gfx] [PATCH v2 2/6] drm/i915/gsc: Skip the version check when fetching the " Daniele Ceraolo Spurio
2022-12-08 5:23 ` Teres Alexis, Alan Previn
2022-12-06 1:19 ` [Intel-gfx] [PATCH v2 3/6] drm/i915/gsc: GSC firmware loading Daniele Ceraolo Spurio
2022-12-06 5:15 ` [Intel-gfx] [PATCH] " Daniele Ceraolo Spurio
2022-12-07 10:16 ` Teres Alexis, Alan Previn
2022-12-07 16:46 ` Ceraolo Spurio, Daniele [this message]
2022-12-06 1:19 ` [Intel-gfx] [PATCH v2 4/6] drm/i915/gsc: Do a driver-FLR on unload if GSC was loaded Daniele Ceraolo Spurio
2022-12-06 8:52 ` Rodrigo Vivi
2022-12-06 1:19 ` [Intel-gfx] [PATCH v2 5/6] drm/i915/gsc: Disable GSC engine and power well if FW is not selected Daniele Ceraolo Spurio
2022-12-06 1:19 ` [Intel-gfx] [PATCH v2 6/6] drm/i915/mtl: MTL has one GSC CS on the media GT Daniele Ceraolo Spurio
2022-12-06 2:41 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Add support for GSC FW loading (rev2) Patchwork
2022-12-06 5:30 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add support for GSC FW loading (rev3) Patchwork
2022-12-06 5:31 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-12-06 5:57 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-12-06 7:15 ` [Intel-gfx] ✓ 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=64b04c01-471b-ded6-2bc3-13319f3b01c6@intel.com \
--to=daniele.ceraolospurio@intel.com \
--cc=alan.previn.teres.alexis@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--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