On Wed, 2022-12-21 at 12:21 +0200, Jani Nikula wrote:
> On Tue, 20 Dec 2022, Alan Previn wrote:
> >
Alan:[snip]
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > @@ -298,6 +298,11 @@ int intel_pxp_tee_cmd_create_arb_session(struct
> > intel_pxp *pxp,
> >
> > if (ret)
> >
Ignore this, use rev2 instead, apologies for the mistake.
On Tue, 2022-12-20 at 14:03 -0800, Teres Alexis, Alan Previn wrote:
> If PXP arb-session is being attempted on older hardware SKUs or
> on hardware with older, unsupported, firmware versions, then don't
> report th
On Wed, 2022-12-14 at 14:37 +0530, Suraj Kandpal wrote:
> Add function that takes care of sending command to gsc cs. We start
> of with allocation of memory for our command intel_hdcp_gsc_message that
> contains gsc cs memory header as directed in specs followed by the
> actual payload hdcp
On Wed, 2022-12-14 at 14:37 +0530, Kandpal, Suraj wrote:
> HDCP and PXP will require a common function to allow it to
> submit commands to the gsc cs. Also adding the gsc mtl header
> that needs to be added on to the existing payloads of HDCP
> and PXP.
>
> Cc: Daniele Ceraolo Spurio
> Cc:
On Thu, 2022-12-08 at 09:29 +, Tvrtko Ursulin wrote:
> Just some small comments and questions below.
>
> On 08/12/2022 05:01, Alan Previn wrote:
> > Starting with MTL, there will be two GT-tiles, a render and media
> >
Alan:[snip]
> IMO this looks great now - pretty self-documenting, all
On Mon, 2022-12-05 at 17:19 -0800, Ceraolo Spurio, Daniele wrote:
> The current exectation from the FW side is that the driver will query
> the GSC FW version after the FW is loaded, similarly to what the mei
> driver does on DG2. However, we're discussing with the FW team if there
> is a way to
On Mon, 2022-12-05 at 17:19 -0800, Ceraolo Spurio, Daniele wrote:
> On MTL the GSC FW needs to be loaded on the media GT by the graphics
> driver. We're going to treat it like a new uc_fw, so add the initial
> defs and init/fini functions for it.
>
> Similarly to the other FWs, the GSC FW path
On Wed, 2022-12-07 at 13:46 +, Tvrtko Ursulin wrote:
> [Side note - your email client somehow manages to make a mess of line wraps
> so after a few replies it is super hard to follow the quote. Don't know
> how/what/why but I don't have this problem on the mailing list with other
> folks so
On Wed, 2022-12-07 at 10:17 +, Tvrtko Ursulin wrote:
> Right, Fixes: and cc stable 5.18+ then (for ADL-P), *if* the upstream
> logger tool actually works and we expect to asks users to use it.
Righ, in that case, will skip the fixes tag since the logger is completely
broken today upstream
On Wed, 2022-12-07 at 10:10 +, Tvrtko Ursulin wrote:
> On 06/12/2022 18:26, Teres Alexis, Alan Previn wrote:
> >
> >
> > On Tue, 2022-12-06 at 10:04 +, Tvrtko Ursulin wrote:
> > > On 06/12/2022 00:03, 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
On Mon, 2022-12-05 at 21:15 -0800, Ceraolo Spurio, Daniele wrote:
> GSC FW is loaded by submitting a dedicated
On Tue, 2022-12-06 at 21:35 +, Teres Alexis, Alan Previn wrote:
> On Tue, 2022-12-06 at 10:14 +, Tvrtko Ursulin wrote:
> > On 06/12/2022 09:20, Alan Previn wrote:
> > > Add usage of unaligned wc mempy in read_update_log_buffer
> > > as newer formats of GuC deb
will have to get back on this - but it will be tied to a specific GuC version
as opposed to a platform.
On Tue, 2022-12-06 at 10:14 +, Tvrtko Ursulin wrote:
> On 06/12/2022 09:20, Alan Previn wrote:
> > Add usage of unaligned wc mempy in read_update_log_buffer
> > as newer formats of GuC
Apologies, ignore this - typo on rev count - will resend with proper v10
subject (and cancel CI)
On Tue, 2022-12-06 at 13:27 -0800, Teres Alexis, Alan Previn wrote:
> Starting with MTL, there will be two GT-tiles, a render and media
> tile. PXP as a service for supporting wor
On Mon, 2022-12-05 at 21:06 -0800, Ceraolo Spurio, Daniele wrote:
>
> On 12/5/2022 4:03 PM, Alan Previn wrote:
Alan:[snip]
> > @@ -39,18 +45,26 @@
> >* performed via the mei_pxp component module.
> >*/
> >
> > -struct intel_gt *pxp_to_gt(const struct intel_pxp *pxp)
> > +bool
On Tue, 2022-12-06 at 10:04 +, Tvrtko Ursulin wrote:
> On 06/12/2022 00:03, Alan Previn wrote:
> >
Alan: [snip]
>
> >
> > -struct intel_gt *pxp_to_gt(const struct intel_pxp *pxp)
> > +bool intel_pxp_is_supported(const struct intel_pxp *pxp)
> > {
> > - return container_of(pxp,
On Mon, 2022-12-05 at 18:04 -0800, Alan Previn Teres Alexis wrote:
> On Wed, 2022-07-20 at 12:08 -0700, Dixit, Ashutosh wrote:
> > On Mon, 09 May 2022 14:01:51 -0700, Alan Previn wrote:
> > >
> > > All other GuC Relay Logging debugfs handles including recent
> > > additions are under the
On Wed, 2022-07-20 at 12:08 -0700, Dixit, Ashutosh wrote:
> On Mon, 09 May 2022 14:01:51 -0700, Alan Previn wrote:
> >
> > All other GuC Relay Logging debugfs handles including recent
> > additions are under the 'i915/gt/uc/path' so let's also move
> > 'guc_log_relay_chan' to its proper home
>
Alan:snip
>
> > void intel_guc_log_debugfs_register(struct intel_guc_log *log,
> > @@ -204,7 +204,7 @@ void intel_guc_log_debugfs_register(struct
> > intel_guc_log *log,
> > { "guc_log_dump", _log_dump_fops, NULL },
> > { "guc_load_err_log_dump",
On Tue, 2022-07-19 at 19:49 -0700, Dixit, Ashutosh wrote:
> On Mon, 09 May 2022 14:01:48 -0700, Alan Previn wrote:
> >
Alan: [snip]
Alan: This patch is not needed any longer because it was also part of another
re-factor related to error-capture and
debug-log-sizing management changes that got
It's been a while - trying to resurrect this now.
On Tue, 2022-07-19 at 20:40 -0700, Dixit, Ashutosh wrote:
> On Mon, 09 May 2022 14:01:49 -0700, Alan Previn wrote:
> >
> >
Alan: [snip]
> > +#define GUC_LOG_RELAY_SUBBUF_COUNT 8
> > +u32 intel_guc_log_relay_subbuf_count(struct intel_guc_log
On Mon, 2022-12-05 at 11:53 -0800, Ceraolo Spurio, Daniele wrote:
>
Alan:[snip]
> >
> > ext_data->flags |= I915_BO_PROTECTED;
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > index 29e9e8d5b6fe..ed74d173a092 100644
On Mon, 2022-12-05 at 12:57 -0500, Vivi, Rodrigo wrote:
> On Fri, Dec 02, 2022 at 03:28:21PM -0800, Alan Previn wrote:
> >
> >
> >
Alan: [snip]
> > @@ -1168,6 +1176,8 @@ static int i915_drm_prepare(struct drm_device *dev)
> > {
> > struct drm_i915_private *i915 = to_i915(dev);
> >
>
Below failure is not related to PXP (PXP is not supported on SKL).
Additionally, towards the end of dmesg seems like gt got wedged when attempting
a completely different igt selftest which bailed on a timeout causing locking
issues.
...alan
On Sat, 2022-12-03 at 10:18 +, Patchwork wrote:
++Rodrigo, Daniele, Jani.
Hey folks - any concerns with this approach?
i915->pxp--->[feature functions]
|---> [tee-backends-folder]
|--->mei-pxp transport functions (legacy)
|--->gsccs transport functions (mtl+)
tee backend folder
On Fri, 2022-12-02 at 11:22 -0500, Vivi, Rodrigo wrote:
> On Thu, Dec 01, 2022 at 05:14:07PM -0800, Alan Previn wrote:
> > Starting with MTL, there will be two GT-tiles, a render and media
> > tile. PXP as a service for supporting workloads with protected
> > contexts and protected buffers can
i just realized nothing external to PXP is calling HAS_PXP so I'll probably
drop this macro and create a helper for
pxp_debugfs (the only caller).
...alan
On Thu, 2022-12-01 at 23:55 +, Teres Alexis, Alan Previn wrote:
>
> On Tue, 2022-11-29 at 18:02 -0800, Teres Alexis, Alan Previn
On Tue, 2022-11-29 at 18:02 -0800, Teres Alexis, Alan Previn wrote:
Alan: [snip]
> + newpxp->ctrl_gt = pxp_get_ctrl_gt(newpxp->i915);
> +
> + if (!newpxp->ctrl_gt)
> + return -ENODEV;
>
> /*
>* If HuC is loaded by GSC but PXP is
> > struct intel_pxp {
> > + /** @i915: back poiner to i915*/
> > + struct drm_i915_private *i915;
>
> do you really need this pointer back here?
> or using a container_of should be enough?
I realize i can drop the i915 backptr as i can use pxp->ctrl_gt->i915.
Few nits - most of which are repeats from existing review comments.
I did have 1 feedback. Functionally, code logic is correct.
To speed things up, I'll provide a conditional R-b if you address the feedback
below + fix the the BIT3->to-BIT4 uncore-
flags fix. Others are nits in my book:
I only have one minor nits below. Rodrigo already captured other minor issues.
Functionally, all LGTM so
Reviewed-by: Alan Previn
On Mon, 2022-11-21 at 15:16 -0800, Ceraolo Spurio, Daniele wrote:
> GSC FW is loaded by submitting a dedicated command via the GSC engine.
> The memory area used for
On Wed, 2022-11-30 at 11:20 +, Patchwork wrote:
> Patch Details
> Series: series starting with [v6,1/1] drm/i915/pxp: Promote pxp subsystem to
> top-level of i915 URL:
> https://patchwork.freedesktop.org/series/111463/ State: failure Details:
>
On Wed, 2022-11-30 at 17:42 +, Vivi, Rodrigo wrote:
> On Wed, 2022-11-30 at 09:32 -0800, Matt Roper wrote:
> > On Tue, Nov 29, 2022 at 06:02:45PM -0800, Alan Previn wrote:
> > > Starting with MTL, there will be two GT-tiles, a render and media
> > > tile. PXP as a service for supporting
> > >
> > > Please let's avoid the ** here and everywhere.
> > >
> > Alan: In order to to avoid causing the entire driver into a rebuild because
> > of any change in the intel_pxp structure,
> > the only way to accomplish that is to use a ptr in i915. But using a ptr
> > means we allocate
On Wed, 2022-11-30 at 17:47 -0800, Juston Li wrote:
> On Mon, 2022-11-28 at 16:48 -0800, Alan Previn wrote:
> >
> >
> >
Alan:[snip]
> > +#define INTEL_PXP_MAX_HWDRM_SESSIONS 16
>
> This isn't need anymore, otherwise
>
> Reviewed-by: Juston Li
>
Alan: Thanks - yeah - will respin a final
>
Alan: [snip]
> In general, no need for cover letter in single/standalone patches.
> In this case, I believe this here is a very good information to be on the
> commit message. It looks more complete and informative for later history,
> then the current one.
>
>
Alan: Okay will republish as
++Nikula if he has suggestions on the bottom most comment.
On Tue, 2022-11-29 at 16:28 -0500, Vivi, Rodrigo wrote:
> On Mon, Nov 28, 2022 at 04:31:52PM -0800, Alan Previn wrote:
> > Starting with MTL, there will be two GT-tiles, a render and media
> > tile. PXP as a service for supporting
Besides the nit below, just would like to echo the same thing Nikula said about
not including the type definition in the
main uc header (which i know can be a bit more work especially if we go with
allocation of the structure at init time
and using a ptr in the uc structure).
That said,
On Mon, 2022-11-28 at 16:31 -0800, Alan Previn wrote:
> Starting with MTL, there will be two GT-tiles, a render and media
> tile. PXP as a service for supporting workloads with protected
> contexts and protected buffers can be subscribed by process
>
>
Alan: [snip]
> diff --git
(++tagging Rodrigo)
This series is a replacement for
https://patchwork.freedesktop.org/series/109429/. Patchwork bestowed a new URL
as the
series is significantly different now with the new design approach direction
from Rodrigo.
...alan
On Mon, 2022-11-28 at 16:31 -0800, Alan Previn wrote:
On Mon, 2022-11-21 at 14:14 -0800, Juston Li wrote:
> > Alan:[snip]
> >
> > > > +void intel_pxp_end(struct intel_pxp *pxp)
> > > > +{
> > > > + struct drm_i915_private *i915 = pxp_to_gt(pxp)->i915;
> > > > + intel_wakeref_t wakeref;
> > > > +
> > > > + if
On Mon, 2022-11-21 at 16:14 -0800, Juston Li wrote:
> On Thu, 2022-11-17 at 16:36 -0800, Alan Previn wrote:
> >
Alan: [snip]
> > +void intel_pxp_tee_end_all_fw_sessions(struct intel_pxp *pxp, u32
> > sessions_mask)
> > +{
> > + int n;
> > +
> > + for (n = 0; n <
typo correction...
On Tue, 2022-11-22 at 12:13 -0800, Alan Previn Teres Alexis wrote:
> After a more comprehensive offline discussion with Daniele and Rodrigo,
> design direction was made to go with Option2
> where we elevate pxp to a global subsystem and within it it establish a
> pointer to
the controls
being gt specific).
...alan
On Tue, 2022-11-22 at 13:17 +0200, Jani Nikula wrote:
> On Thu, 17 Nov 2022, "Teres Alexis, Alan Previn"
> wrote:
> > Respectfully and humbly, i would like to request where is the coding
> > guideline for function naming when u
After a more comprehensive offline discussion with Daniele and Rodrigo, design
direction was made to go with Option2
where we elevate pxp to a global subsystem and within it it establish a pointer
to the correct gt for pxp-controls. This
also reflects the current HW architectures where the PXP
On Tue, 2022-11-22 at 12:57 -0500, Vivi, Rodrigo wrote:
>
>
[Alan:snip]
> As I had told I don't have a strong preference, as long as it keep clean
> and without these many helpers of something "on_gt"...
>
> If this stays inside the gt, just make sure that you call for all the gts,
> but
On Mon, 2022-11-21 at 10:39 -0800, Juston Li wrote:
> On Thu, 2022-11-17 at 16:36 -0800, Alan Previn wrote:
> > A driver bug was recently discovered where the security firmware was
> > receiving internal HW signals indicating that session key expirations
> > had occurred. Architecturally, the
On Mon, 2022-11-21 at 14:06 +, Vivi, Rodrigo wrote:
> On Mon, 2022-11-21 at 11:39 +, Tvrtko Ursulin wrote:
> >
> > On 17/11/2022 22:34, Teres Alexis, Alan Previn wrote:
> > > On Thu, 2022-11-17 at 11:02 -0500, Vivi, Rodrigo wrote:
> > > > On Wed, No
On Mon, 2022-11-21 at 11:39 +, Tvrtko Ursulin wrote:
> On 17/11/2022 22:34, Teres Alexis, Alan Previn wrote:
> > On Thu, 2022-11-17 at 11:02 -0500, Vivi, Rodrigo wrote:
> > > On Wed, Nov 16, 2022 at 04:30:13PM -0800, Alan Previn wrote:
> > > > In preparat
Thank you Jani - this was clearly my mistake (apologies to Daniele/Rodrigo) -
didn't realize we had this documented. I
will go through that first.
...alan
On Mon, 2022-11-21 at 14:12 +0200, Jani Nikula wrote:
> On Mon, 21 Nov 2022, Tvrtko Ursulin wrote:
> > On 17/11/2022 22:34, Ter
On Thu, 2022-11-17 at 16:36 -0800, Alan Previn wrote:
> A driver bug was recently discovered where the security firmware was
> receiving internal HW signals indicating that session key expirations
> had occurred. Architecturally, the firmware was expecting a response
> from the GuC to acknowledge
On Thu, 2022-11-17 at 11:04 -0500, Vivi, Rodrigo wrote:
> On Wed, Nov 16, 2022 at 04:30:14PM -0800, Alan Previn wrote:
> > Make intel_pxp_is_enabled a global check and implicitly find the
> > PXP-owning-GT.
> >
> > PXP feature support is a device-config flag. In preparation for MTL
> > PXP
On Thu, 2022-11-17 at 11:02 -0500, Vivi, Rodrigo wrote:
> On Wed, Nov 16, 2022 at 04:30:13PM -0800, Alan Previn wrote:
> > In preparation for future MTL-PXP feature support, PXP control
> > context should only valid on the correct gt tile. Depending on the
> > device-info this depends on which
just recapping offline conversation summary - we agreed on:
intel_pxp_enabled(i915)
intel_pxp_enabled_on_gt(pxp)
(where one is wrapper over the other, the action part of the function
name stays the same).
...alan
On Mon, 2022-11-14 at 21:13 -0800, Alan Previn Teres Alexis wrote:
>
>
I'm assuming that you have verified that the GuC ADS code is calling for the
registration of the GSC capture register
list accordingly and for the correct tile. That said:
Reviewed-by: Alan Previn
On Thu, 2022-11-10 at 16:18 -0800, Ceraolo Spurio, Daniele wrote:
> For the GSC engine we only
On Mon, 2022-11-14 at 20:17 -0800, Ceraolo Spurio, Daniele wrote:
>
> On 10/21/2022 10:39 AM, Alan Previn wrote:
> > Make intel_pxp_is_active a global check and implicitly find
> > the PXP-owning-GT.
> >
> > As per prior two patches, callers of this function shall now
> > pass in i915 since
On Mon, 2022-11-14 at 20:11 -0800, Ceraolo Spurio, Daniele wrote:
>
> On 10/21/2022 10:39 AM, Alan Previn wrote:
> > @@ -68,11 +69,34 @@ bool intel_gtpxp_is_supported(struct intel_pxp *pxp)
> > return false;
> > }
> >
> > -bool intel_pxp_is_enabled(const struct intel_pxp *pxp)
> >
On Mon, 2022-11-14 at 20:00 -0800, Ceraolo Spurio, Daniele wrote:
>
> On 10/21/2022 10:39 AM, Alan Previn wrote:
> > In preparation for future MTL-PXP feature support, PXP control
> > @@ -142,22 +166,21 @@ void intel_pxp_init(struct intel_pxp *pxp)
> > {
> > struct intel_gt *gt =
Agreed on all comments - will fix them all. Thanks Daniele, Nikula.
...alan
On Wed, 2022-11-02 at 11:35 +0200, Jani Nikula wrote:
> On Tue, 01 Nov 2022, "Ceraolo Spurio, Daniele"
> wrote:
> > On 10/24/2022 11:40 AM, Alan Previn wrote:
> > > Previously, we only used PXP FW interface version-42
AS per the other rev, below regressions are, once again, unrelated to this
series because this series patch modified code that only get executed if GuC
ADS is being initialized whereas the regressions are on platforms that do not
have GuC enabled (which i further verified in the full dmesg).
The issues reported below are unrelated to the patch because:
1. SKL and ICL do not even support PXP and none of the code path of this series
will get executed.
2. RKL supports PXP but the code paths only get executed when PXP is enabled by
the component binding and activated (via IGT PXP)
I verified that 2 of the 3 the errors reported below are on platforms that
don't support GuC and the dmesgs confirm guc was disabled.
The remaining ICL one, we know ICL doesnt support GuC .. also, additionally,
the error was on a display IGT where CRCs were failing.
That said these errors I
I believe that the issues below are not related to this series because they
were running on platforms that do not use guc-submission. Additionally, both
patches of this series impact steps very early in the guc initialization phase
and never again - and do not impact runtime operation of
with the removal of pxptee_iface_owner and the separation of a global-pxp check
vs a per-gt pxp (is enabled) check, this
patch will get dropped as the latter change would appear in earlier in the
series
On Wed, 2022-10-05 at 21:38 -0700, Alan Previn wrote:
> pxptee_iface_owner
On Mon, 2022-10-17 at 10:03 -0700, Alan Previn Teres Alexis wrote:
> >
> > On Thu, 2022-10-13 at 13:48 -0700, Ceraolo Spurio, Daniele wrote:
> > > >
> > > > On 10/5/2022 9:38 PM, Alan Previn wrote:
> > > > > > In preparation for future MTL-PXP feature support, PXP control
> > > > > > context
On Mon, 2022-10-17 at 10:03 -0700, Alan Previn Teres Alexis wrote:
>
> On Thu, 2022-10-13 at 13:48 -0700, Ceraolo Spurio, Daniele wrote:
> >
> > On 10/5/2022 9:38 PM, Alan Previn wrote:
> > > In preparation for future MTL-PXP feature support, PXP control
> > > context should only valid on the
> > > Also commit message you can aim to wrap at 75 chars as per
> > > submitting-patches.rst.
> > >
> > > > + return -ENODATA;
> > >
> > > Is this a new exit condition or the thing would exit on the !num_regs
> > > check below anyway? Just wondering if the series is only about
Update: One additional change needed... after more testing i have come to
realize that
intel_guc_capture_getlistsize is also being triggered before
ADS-guc-error-capture
register-list population during initialization of the guc-error-capture module
itself
(intel_guc_capture_init). Its getting
Agreed on all the others (as per my other reply to Tvrtko), but on that 2nd
last one:
On Mon, 2022-10-17 at 12:33 -0700, Harrison, John C wrote:
> On 10/14/2022 20:59, Alan Previn wrote:
> > If GuC is being used and we initialized GuC-error-capture,
> > we need to be warning if we don't provide
On Mon, 2022-10-17 at 09:42 +0100, Tvrtko Ursulin wrote:
> On 15/10/2022 04:59, Alan Previn wrote:
> > If GuC is being used and we initialized GuC-error-capture,
> > we need to be warning if we don't provide an error-capture
> > register list in the firmware ADS, for valid GT engines.
> > A
ADL-P doesnt support CCS and DG2 is stll force-probe (so hoping to get this
before DG2 goes live).
...alan
On Mon, 2022-10-17 at 09:43 +0100, Tvrtko Ursulin wrote:
> On 15/10/2022 04:59, Alan Previn wrote:
> > Add compute reglist for GuC error capture.
> >
> > Signed-off-by: Alan Previn
> >
On Thu, 2022-10-13 at 14:10 -0700, Ceraolo Spurio, Daniele wrote:
>
> On 10/5/2022 9:38 PM, Alan Previn wrote:
> > Make intel_pxp_is_enabled implicitly find the PXP-owning-GT.
> > PXP feature support is a device-config flag. In preparation for MTL
> > PXP control-context shall reside on of the
On Thu, 2022-10-13 at 13:48 -0700, Ceraolo Spurio, Daniele wrote:
>
> On 10/5/2022 9:38 PM, Alan Previn wrote:
> > In preparation for future MTL-PXP feature support, PXP control
> > context should only valid on the correct gt tile. Depending on the
> > device-info this mat not necessarily be
On Thu, 2022-10-06 at 23:56 +, Patchwork wrote:
> Patch Details
> Series: Delay disabling GuC scheduling of an idle context URL:
> https://patchwork.freedesktop.org/series/109466/ State:
> failure Details:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109466v1/index.html
> CI Bug
I dont believe either of these failures are related to my changes as ICL and
SKL doesn't support PXP and after re-
looking at the change to "intel_pxp_is_enabled", I am confident it remains
consistent with prior code in that it would
return FALSE for any HW without PXP support after it checks
On Wed, 2022-10-05 at 23:02 -0700, Alan Previn wrote:
> -static inline bool context_has_committed_requests(struct intel_context *ce)
> -{
> - return !!ce->guc_state.number_committed_requests;
> -}
> -
Offline conversation with John Harrison and team matest concluded we dont even
need
the
On Wed, 2022-10-05 at 17:25 -0700, Harrison, John C wrote:
> On 9/21/2022 10:32, Alan Previn wrote:
> > @@ -208,6 +210,11 @@ struct intel_context {
> > * each priority bucket
> > */
> > u32 prio_count[GUC_CLIENT_PRIORITY_NUM];
> > + /**
> > +
ld be
> > less than 700K min_size), then lets drop to
> > 1MB allocation.
> >
> > ...alan
> Sounds good to me.
>
> John.
>
> >
> >
> > On Mon, 2022-10-03 at 16:51 -0700, Harrison, John C wrote:
> > > On 10/3/2022 14:10, Teres Alexis, Alan
I just realize i missed a patch (similar refactoring for pxp-suspend/resume
when caller is external).
Will post a rev2 with that missing bit. Review can continue on rev1 though
(rev2 will be an additional
patch following the same design proposal).
...alan
On Wed, 2022-10-05 at 12:18 -0700,
0/3/2022 14:10, Teres Alexis, Alan Previn wrote:
> > On Mon, 2022-10-03 at 12:47 -0700, Harrison, John C wrote:
> > > On 10/3/2022 11:28, Teres Alexis, Alan Previn wrote:
> > > > On Fri, 2022-09-30 at 15:35 -0700, Harrison, John C wrote:
> > > > > On 9/30/2022 14:08, Teres Alexis, Alan Previn wrote:
> > > > >
On Mon, 2022-10-03 at 12:47 -0700, Harrison, John C wrote:
> On 10/3/2022 11:28, Teres Alexis, Alan Previn wrote:
> > On Fri, 2022-09-30 at 15:35 -0700, Harrison, John C wrote:
> > > On 9/30/2022 14:08, Teres Alexis, Alan Previn wrote:
> > > > I disagree because its
Both of below are not related to GuC: ICL didn't have GuC support and TGL was
not using GuC-submission.
...alan
On Sat, 2022-10-01 at 20:05 +, Patchwork wrote:
> Patch Details
> Series:Fix Guc-Err-Capture sizing warning
>
On Fri, 2022-09-30 at 15:35 -0700, Harrison, John C wrote:
> On 9/30/2022 14:08, Teres Alexis, Alan Previn wrote:
> > I disagree because its unlikely that all engines can reset all at once (we
> > probably have bigger problems at the at
> > point) and if they all occurre
Hi John - how would you like to proceed? I have re-rev'd as per your original
review comment on rev1.
Shall we adopt this rev2's "drm_warn" for the worst-case (knowing well that
gpu_core_dump is still an external subsystem
that can cull our data, but at least within this subsystem we are adding
I disagree because its unlikely that all engines can reset all at once (we
probably have bigger problems at the at
point) and if they all occurred within the same G2H handler scheduled worker
run, our current gpu_coredump framework
would just discard the ones after the first one and so it
On Tue, 2022-09-13 at 16:22 -0700, Ceraolo Spurio, Daniele wrote:
> Wait on the fence to be signalled to avoid the submissions finding HuC
> not yet loaded.
>
> v2: use dedicaded wait_queue_entry for waiting in HuC load, as submitq
> can't be re-used for it.
>
> Signed-off-by: Daniele Ceraolo
On Fri, 2022-09-16 at 08:36 -0700, Ceraolo Spurio, Daniele wrote:
>
> On 9/16/2022 1:58 AM, Tvrtko Ursulin wrote:
> > On 16/09/2022 08:53, Teres Alexis, Alan Previn wrote:
> > > On Thu, 2022-09-15 at 09:48 +0100, Tvrtko Ursulin wrote:
> > > > On 15
On Fri, 2022-09-16 at 09:58 +0100, Tvrtko Ursulin wrote:
> On 16/09/2022 08:53, Teres Alexis, Alan Previn wrote:
> > On Thu, 2022-09-15 at 09:48 +0100, Tvrtko Ursulin wrote:
> > > On 15/09/2022 03:12, Alan Previn wrote:
> > > > From: Matthew Brost
On Fri, 2022-09-16 at 08:36 -0700, Ceraolo Spurio, Daniele wrote:
>
>
alan: [snip]
> > > > > +/*
> > > > > + * If the context gets closed while the execbuf is ongoing,
> > > > > the context
> > > > > + * close code will race with the below code to cancel the
> > > > > delayed
On Fri, 2022-09-16 at 08:36 -0700, Ceraolo Spurio, Daniele wrote:
>
> On 9/16/2022 1:58 AM, Tvrtko Ursulin wrote:
> > On 16/09/2022 08:53, Teres Alexis, Alan Previn wrote:
> > > On Thu, 2022-09-15 at 09:48 +0100, Tvrtko Ursulin wrote:
> > > > On 15
On Thu, 2022-09-15 at 09:48 +0100, Tvrtko Ursulin wrote:
> On 15/09/2022 03:12, Alan Previn wrote:
> > From: Matthew Brost
> >
> > Add a delay, configurable via debugfs (default 34ms), to disable
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
>
Nit: wish some of those macro param names were more descriptive, example :
fw_def -> fw_namer or prefix -> gen
But that's irrelevant here, so
Reviewed-by: Alan Previn
On Thu, 2022-09-08 at 17:16 -0700, Ceraolo Spurio, Daniele wrote:
> The fw name is different and we need to record the fact
Reviewed-by: Alan Previn
On Thu, 2022-09-08 at 17:16 -0700, Ceraolo Spurio, Daniele wrote:
> Given that HuC load is delayed on DG2, this patch adds support for a fence
> that can be used to wait for load completion. No waiters are added in this
> patch (they're coming up in the next one), to
Nearly identical as before:
Reviewed-by: Alan Previn
On Thu, 2022-09-08 at 17:16 -0700, Ceraolo Spurio, Daniele wrote:
> The GSC will perform both the load and the authentication, so we just
> need to check the auth bit after the GSC has replied.
> Since we require the PXP module to load the
Yup - simple stuff - LGTM:
Reviewed-by: Alan Previn
On Fri, 2022-08-19 at 15:53 -0700, Daniele Ceraolo Spurio wrote:
> The current HuC status getparam return values are a bit confusing in
> regards to what happens in some scenarios. In particular, most of the
> error cases cause the ioctl to
I had provided rb on vers 7 and i see the only difference here in v9 is the
usage of I915_BO_ALLOC_CPU_CLEAR in
gsc_ext_om_alloc saving us a few lines for free. Thus:
Reviewed-by: Alan Previn
On Thu, 2022-09-08 at 00:51 +0300, Winkler, Tomas wrote:
> GSC requires more operational memory than
This patch hasnt changed since v5 and i already provided the R-b then so
re-posting rb so patchworks can pick it up:
Reviewed-by: Alan Previn
On Sat, 2022-08-06 at 15:26 +0300, Winkler, Tomas wrote:
> GSC requires more operational memory than available on chip.
> Reserve 4M of LMEM for GSC
disabled) but instead called
guc_context_sched_disable (no underscore) causing an
infinite loop for mid-disabling.
...alan
On Fri, 2022-08-19 at 16:47 +, Teres Alexis, Alan Previn wrote:
> Will look into this - apologies for the trouble Matt.
> ...alan
>
> -Original Message
Will look into this - apologies for the trouble Matt.
...alan
-Original Message-
From: Harrison, John C
Sent: Friday, August 19, 2022 8:46 AM
To: Auld, Matthew ; intel-gfx@lists.freedesktop.org
Cc: Brost, Matthew ; Teres Alexis, Alan Previn
Subject: Re: [PATCH] Revert "drm/i91
On Tue, 2022-08-16 at 15:45 -0700, Harrison, John C wrote:
> On 8/15/2022 19:17, Alan Previn wrote:
> > From: Matthew Brost
> >
> > Add a delay, configurable via debugfs (default 34ms), to disable
> > (default is 3/4) of the guc_ids.
> are in use.
>
my bad - got clipped - will fix.
> > ---
201 - 300 of 409 matches
Mail list logo
