From: "Teres Alexis, Alan Previn" <alan.previn.teres.alexis@intel.com>
To: "Ceraolo Spurio, Daniele" <daniele.ceraolospurio@intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>
Cc: "Belgaumkar, Vinay" <vinay.belgaumkar@intel.com>,
"Harrison, John C" <john.c.harrison@intel.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 2/6] drm/i915/uc/gsc: fixes and updates for GSC memory allocation
Date: Tue, 23 May 2023 00:13:50 +0000 [thread overview]
Message-ID: <dc45dc7e07ebbbf5a0e40831ba44c206d86cc93a.camel@intel.com> (raw)
In-Reply-To: <20230505160415.889525-3-daniele.ceraolospurio@intel.com>
On Fri, 2023-05-05 at 09:04 -0700, Ceraolo Spurio, Daniele wrote:
> A few fixes/updates are required around the GSC memory allocation and it
> is easier to do them all at the same time. The changes are as follows:
alan:snip
> @@ -109,38 +110,21 @@ static int gsc_fw_load_prepare(struct intel_gsc_uc *gsc)
> {
> struct intel_gt *gt = gsc_uc_to_gt(gsc);
> struct drm_i915_private *i915 = gt->i915;
> - struct drm_i915_gem_object *obj;
> - void *src, *dst;
> + void *src;
alan:snip
>
> - memset(dst, 0, obj->base.size);
> - memcpy(dst, src, gsc->fw.size);
> + memset_io(gsc->local_vaddr, 0, gsc->local->size);
> + memcpy_toio(gsc->local_vaddr, src, gsc->fw.size);
alan: i wonder if it there is benefit to do the memcpy_toio first
and then do the memset_io but only for the balance of area from
offset 'gsc->fw.size' for (gsc->local->size - gsc->fw.size) bytes.
alan:snip
> --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
> @@ -130,26 +130,85 @@ void intel_gsc_uc_init_early(struct intel_gsc_uc *gsc)
> }
> }
>
> +static int gsc_allocate_and_map_vma(struct intel_gsc_uc *gsc, u32 size)
alan:snip
> + obj = i915_gem_object_create_stolen(gt->i915, size);
> + if (IS_ERR(obj))
> + return PTR_ERR(obj);
> +
> + vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, 0);
alan: should we be passing in the PIN_MAPPABLE flag into the last param?
alan:snip
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h
> index a2a0813b8a76..c01286dddbdb 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h
> @@ -18,6 +18,7 @@ struct intel_gsc_uc {
>
> /* GSC-specific additions */
> struct i915_vma *local; /* private memory for GSC usage */
> + void __iomem *local_vaddr; /* pointer to access the private memory */
alan:nit: relooking at the these variable names that originate from
last year's patch you worked on introducing gsc_uc, i am wondering now
if we should rename "local" to "privmem" and local_vaddr becomes privmem_vaddr.
(no significant reason other than improving readibility of the code)
WARNING: multiple messages have this Message-ID (diff)
From: "Teres Alexis, Alan Previn" <alan.previn.teres.alexis@intel.com>
To: "Ceraolo Spurio, Daniele" <daniele.ceraolospurio@intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 2/6] drm/i915/uc/gsc: fixes and updates for GSC memory allocation
Date: Tue, 23 May 2023 00:13:50 +0000 [thread overview]
Message-ID: <dc45dc7e07ebbbf5a0e40831ba44c206d86cc93a.camel@intel.com> (raw)
In-Reply-To: <20230505160415.889525-3-daniele.ceraolospurio@intel.com>
On Fri, 2023-05-05 at 09:04 -0700, Ceraolo Spurio, Daniele wrote:
> A few fixes/updates are required around the GSC memory allocation and it
> is easier to do them all at the same time. The changes are as follows:
alan:snip
> @@ -109,38 +110,21 @@ static int gsc_fw_load_prepare(struct intel_gsc_uc *gsc)
> {
> struct intel_gt *gt = gsc_uc_to_gt(gsc);
> struct drm_i915_private *i915 = gt->i915;
> - struct drm_i915_gem_object *obj;
> - void *src, *dst;
> + void *src;
alan:snip
>
> - memset(dst, 0, obj->base.size);
> - memcpy(dst, src, gsc->fw.size);
> + memset_io(gsc->local_vaddr, 0, gsc->local->size);
> + memcpy_toio(gsc->local_vaddr, src, gsc->fw.size);
alan: i wonder if it there is benefit to do the memcpy_toio first
and then do the memset_io but only for the balance of area from
offset 'gsc->fw.size' for (gsc->local->size - gsc->fw.size) bytes.
alan:snip
> --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
> @@ -130,26 +130,85 @@ void intel_gsc_uc_init_early(struct intel_gsc_uc *gsc)
> }
> }
>
> +static int gsc_allocate_and_map_vma(struct intel_gsc_uc *gsc, u32 size)
alan:snip
> + obj = i915_gem_object_create_stolen(gt->i915, size);
> + if (IS_ERR(obj))
> + return PTR_ERR(obj);
> +
> + vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, 0);
alan: should we be passing in the PIN_MAPPABLE flag into the last param?
alan:snip
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h
> index a2a0813b8a76..c01286dddbdb 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h
> @@ -18,6 +18,7 @@ struct intel_gsc_uc {
>
> /* GSC-specific additions */
> struct i915_vma *local; /* private memory for GSC usage */
> + void __iomem *local_vaddr; /* pointer to access the private memory */
alan:nit: relooking at the these variable names that originate from
last year's patch you worked on introducing gsc_uc, i am wondering now
if we should rename "local" to "privmem" and local_vaddr becomes privmem_vaddr.
(no significant reason other than improving readibility of the code)
next prev parent reply other threads:[~2023-05-23 0:14 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-05 16:04 [PATCH 0/6] drm/i915: GSC FW support for MTL Daniele Ceraolo Spurio
2023-05-05 16:04 ` [Intel-gfx] " Daniele Ceraolo Spurio
2023-05-05 16:04 ` [PATCH 1/6] DO NOT REVIEW: drm/i915: HuC loading and authentication " Daniele Ceraolo Spurio
2023-05-05 16:04 ` [Intel-gfx] " Daniele Ceraolo Spurio
2023-05-05 16:04 ` [PATCH 2/6] drm/i915/uc/gsc: fixes and updates for GSC memory allocation Daniele Ceraolo Spurio
2023-05-05 16:04 ` [Intel-gfx] " Daniele Ceraolo Spurio
2023-05-23 0:13 ` Teres Alexis, Alan Previn [this message]
2023-05-23 0:13 ` Teres Alexis, Alan Previn
2023-05-23 15:21 ` Ceraolo Spurio, Daniele
2023-05-23 15:21 ` [Intel-gfx] " Ceraolo Spurio, Daniele
2023-06-06 0:00 ` Teres Alexis, Alan Previn
2023-06-06 0:00 ` [Intel-gfx] " Teres Alexis, Alan Previn
2023-05-05 16:04 ` [PATCH 3/6] drm/i915/uc/gsc: extract release and security versions from the gsc binary Daniele Ceraolo Spurio
2023-05-05 16:04 ` [Intel-gfx] " Daniele Ceraolo Spurio
2023-05-25 5:14 ` Teres Alexis, Alan Previn
2023-05-25 5:14 ` [Intel-gfx] " Teres Alexis, Alan Previn
2023-05-25 16:56 ` Ceraolo Spurio, Daniele
2023-05-25 16:56 ` [Intel-gfx] " Ceraolo Spurio, Daniele
2023-05-25 22:03 ` Teres Alexis, Alan Previn
2023-05-25 22:03 ` [Intel-gfx] " Teres Alexis, Alan Previn
2023-05-27 1:27 ` Ceraolo Spurio, Daniele
2023-05-27 1:27 ` [Intel-gfx] " Ceraolo Spurio, Daniele
2023-06-05 23:51 ` Teres Alexis, Alan Previn
2023-06-05 23:51 ` [Intel-gfx] " Teres Alexis, Alan Previn
2023-05-05 16:04 ` [PATCH 4/6] drm/i915/uc/gsc: query the GSC FW for its compatibility version Daniele Ceraolo Spurio
2023-05-05 16:04 ` [Intel-gfx] " Daniele Ceraolo Spurio
2023-05-25 23:29 ` Teres Alexis, Alan Previn
2023-05-25 23:29 ` [Intel-gfx] " Teres Alexis, Alan Previn
2023-05-05 16:04 ` [PATCH 5/6] drm/i915/uc/gsc: define gsc fw Daniele Ceraolo Spurio
2023-05-05 16:04 ` [Intel-gfx] " Daniele Ceraolo Spurio
2023-05-25 23:48 ` Teres Alexis, Alan Previn
2023-05-25 23:48 ` [Intel-gfx] " Teres Alexis, Alan Previn
2023-06-01 0:32 ` Ceraolo Spurio, Daniele
2023-06-01 0:32 ` [Intel-gfx] " Ceraolo Spurio, Daniele
2023-05-05 16:04 ` [PATCH 6/6] drm/i915/uc/gsc: Add a gsc_info debugfs Daniele Ceraolo Spurio
2023-05-05 16:04 ` [Intel-gfx] " Daniele Ceraolo Spurio
2023-05-26 22:57 ` Teres Alexis, Alan Previn
2023-05-26 22:57 ` [Intel-gfx] " Teres Alexis, Alan Previn
2023-06-01 0:25 ` Ceraolo Spurio, Daniele
2023-06-01 0:25 ` [Intel-gfx] " Ceraolo Spurio, Daniele
2023-06-05 23:46 ` Teres Alexis, Alan Previn
2023-06-05 23:46 ` [Intel-gfx] " Teres Alexis, Alan Previn
2023-06-05 23:53 ` Ceraolo Spurio, Daniele
2023-06-05 23:53 ` [Intel-gfx] " Ceraolo Spurio, Daniele
2023-05-05 21:02 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: GSC FW support for MTL 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=dc45dc7e07ebbbf5a0e40831ba44c206d86cc93a.camel@intel.com \
--to=alan.previn.teres.alexis@intel.com \
--cc=daniele.ceraolospurio@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=john.c.harrison@intel.com \
--cc=vinay.belgaumkar@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.