[PATCH v8 1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915

[Teres Alexis, Alan Previn]

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);
> >  
> > +	intel_pxp_suspend_prepare(i915->pxp);
> > +
> >  	/*
> >  	 * NB intel_display_suspend() may issue new requests after we've
> >  	 * ostensibly marked the GPU as ready-to-sleep here. We need to
> > @@ -1248,6 +1258,8 @@ static int i915_drm_suspend_late(struct drm_device *dev, bool hibernation)
> >  
> >  	disable_rpm_wakeref_asserts(rpm);
> >  
> > +	intel_pxp_suspend(dev_priv->pxp);
> > +
> 
> Before this patch the pxp_suspend was done right after uc_suspend.
> Right now, the uc_suspend will happen couple lines below.
> 
> 
> 
Okay - I see this 2nd level flow change but this has no functional change. I have gone through the codes and whether
intel_pxp_suspend came in after i915_gem_suspend_late or the middle of gt_suspend_late (after us_suspend), it does not
make any difference. intel_pxp_suspend only disables display-control-events on KCR register and disables CRYPTO-IRQ
registers. GuC or HuC is only ever doing any PXP related work if it receives workloads via exec-buf (kernel side PXP
workload subsmission is limited to arb-session creation today OR, in future, teardown-flows at suspend_prepare - this is
upcoming change in flight). That said, since the GT is already quiesced in suspend_prepare, therefore HuC or GuC should
be not doing anything inside of i915_suspend_late whether its before i915_gem_suspend_late or before uc_suspend.


> If this is okay, why can't we move already the pxp_suspend to the
> suspend function and need to keep this in the suspend late?
> 
We can - but i dont see any difference in doing so functionally speaking - i do however prefer minimizing the code flow
changes to 

> Or we don't change the flow at all, or we already fix the unbalanced
> thing.
> I believe the first option is better and changing the flow in a
> separated patch is better.
> 
Actually, I rather fix the symmetry at the this level: As part of this feature to promote PXP - Gt becomes a dependency
of PXP. So at init, we ensure GT is init first and then we init PXP. Therefore we should do the opposite for fini -
ensure PXP fini is done first and the cleanup the GT. That why the move above. But as the global i915 level we are
keeping it within suspend_late - after everything was quiesced in suspend_prepare.

> Specially because I don't understand if huc has any dependency on
> the pxp. Maybe that was the original reason why that function end up there
> at first place.
> 
> I believe Daniele is the right one to let us know that.
> 
I spoke to Daniele and he confirmed what i explained above.

> >  	i915_gem_suspend_late(dev_priv);
> >  
> >