intel-xe.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: "Michał Winiarski" <michal.winiarski@intel.com>
Cc: "K V P, Satyanarayana" <satyanarayana.k.v.p@intel.com>,
	<intel-xe@lists.freedesktop.org>,
	Michal Wajdeczko <michal.wajdeczko@intel.com>,
	Matthew Brost <matthew.brost@intel.com>,
	Anshuman Gupta <anshuman.gupta@intel.com>
Subject: Re: [PATCH v3] drm/xe/pm: Disable RPM for SR-IOV VFs with no PCIe PM capability]
Date: Mon, 4 Aug 2025 12:54:22 -0400	[thread overview]
Message-ID: <aJDlvknZOh7u0Gdf@intel.com> (raw)
In-Reply-To: <xdrfj24g5nuglrnrnl4twfosd36tgkvs52y4fv5fmkpibtjgby@yfgrjm25fpj7>

On Mon, Aug 04, 2025 at 06:20:57PM +0200, Michał Winiarski wrote:
> On Mon, Aug 04, 2025 at 11:11:39AM -0400, Rodrigo Vivi wrote:
> > On Mon, Aug 04, 2025 at 08:30:12PM +0530, K V P, Satyanarayana wrote:
> > > 
> > > 
> > > On 04-08-2025 20:21, Rodrigo Vivi wrote:
> > > > On Fri, Aug 01, 2025 at 10:00:17PM +0530, Satyanarayana K V P wrote:
> > > > > Enable Runtime Power Management (RPM) for PCI Express devices by utilizing
> > > > > their native Power Management (PM) capabilities. The specification (as per
> > > > > section 5.10.1 in PCI Express® Base Specification Revision 7.0) mandates
> > > > > that Virtual Functions (VFs) without Power Management capability inherit
> > > > > their associated Physical Function's (PF) power state.
> > > > > 
> > > > > As per PCIe spec "If a VF does not implement the PCI Power Management
> > > > > Capability, then the VF behaves as if it had been programmed into the
> > > > > equivalent power state of its associated PF"
> > > > > 
> > > > > Since Intel GPU VFs lack PM capability implementations, VFs power behavior
> > > > 
> > > > If this is a true statement your patch below is wrong.
> > > > It should simply be if (IS_VF) return;
> > > > 
> > > The current GPU VFs are lacking PM capability. But in future, if VFs (new
> > > generation GPUs) support PM capability, then VF should be able to manage PM
> > > on its own. As per spec, if VF does not implement PCI PM capability, it
> > > should follow PF power states. If implemented, VF should manage PM directly.
> > > 
> > > So, checking for both pm_cap and IS_VF.
> > 
> > So the commit message should be written in a way to explain that possibility.
> > 
> > But anyway, please step back for a moment and think about the whole flow
> > itself and the reasoning behind pm_cap.
> > 
> > pci subsystem is the one already checking the pm_caps before doing the
> > pci pm transitions. If the check is not there, please go there and add it
> > to the pci subsystem.
> > 
> > From our side, if we need to avoid that VF follows the PF and goes to sleep,
> > then the PF needs to get an extra refcount for the whole duration of the VF,
> > so PF won't be allowed to sleep then VF will also not sleep.
> 
> PF is already taking the refcount, from PCI perspective, VF device is
> never going into low-power state.
> 
> Main thing to keep in mind here, is that runtime_pm is decoupled from
> PCI subsystem. It's the drivers responsibility to actually trigger PCI
> PM transition into low-power state as part of runtime suspend handling.
> Usually that's one of the last steps, and before that, the driver needs
> to make sure that the state of all the resources is not "lost" after
> moving into low-power state, and the driver is able to recover that
> state as part of runtime resume.
> 
> For VF that doesn't implement pm_caps - that last step, which is moving
> into low-power state is a no-op.
> In other words - for VF w/o PM caps, with the current driver codebase
> we're going through all the driver-specific extra work in suspend/resume
> handlers to end up doing nothing in the end.
> 
> Perhaps the commit message is not expressing that clearly enough, but
> the reasoning behind the patch is simple - if PCI PM transition is a
> no-op, don't do any extra work (by not using runtime PM).
> 
> Does that sound reasonable?

Finally a reasonable explanation, thank you!

Satyanarayana, please make sure that this is pretty clear in the commit
message, and also use if (IS_VF() && !pm_cap) instead of the inverted negative or.

Also worth a comment in the code as well right before the if:

/* For VF that doesn't implement pm_caps, the rpm functions are no-op */

Thanks,
Rodrigo.

> 
> Thanks,
> -Michał
> 
> > 
> > > 
> > > > > must mirror their PF's state. During VF creation, the PF remains active
> > > > > from the PCI subsystem perspective. To maintain consistency, explicitly
> > > > > disable RPM for VFs missing PM capability to ensure they follow their PF's
> > > > > power management status rather than entering low-power states
> > > > > independently.
> > > > > 
> > > > > Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
> > > > > Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> > > > > Cc: Matthew Brost <matthew.brost@intel.com>
> > > > > Cc: Michał Winiarski <michal.winiarski@intel.com>
> > > > > Cc: Anshuman Gupta <anshuman.gupta@intel.com>
> > > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > 
> > > > > ---
> > > > > V2 -> V3:
> > > > > - Fixed review comments (Michal Wajdeczko).
> > > > > 
> > > > > V1 -> V2:
> > > > > - Disable RPM only for VF devices when PM cap is not implemented.
> > > > > ---
> > > > >   drivers/gpu/drm/xe/xe_pm.c | 14 ++++++++++++++
> > > > >   1 file changed, 14 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/xe/xe_pm.c b/drivers/gpu/drm/xe/xe_pm.c
> > > > > index 8aae66660931..019de04fa7bb 100644
> > > > > --- a/drivers/gpu/drm/xe/xe_pm.c
> > > > > +++ b/drivers/gpu/drm/xe/xe_pm.c
> > > > > @@ -246,8 +246,18 @@ static bool xe_pm_pci_d3cold_capable(struct xe_device *xe)
> > > > >   static void xe_pm_runtime_init(struct xe_device *xe)
> > > > >   {
> > > > > +	struct pci_dev *pdev = to_pci_dev(xe->drm.dev);
> > > > >   	struct device *dev = xe->drm.dev;
> > > > > +	/*
> > > > > +	 * Disable RPM for VFs if PM cap is not supported.
> > > > > +	 * As per PCIe specification, "If a VF does not implement the PCI Power
> > > > > +	 * Management Capability, then the VF behaves as if it had been programmed
> > > > > +	 * into the equivalent power state of its associated PF"
> > > > > +	 */
> > > > > +	if (!(pdev->pm_cap || !IS_SRIOV_VF(xe)))
> > > > > +		return;
> > > > > +
> > > > >   	/*
> > > > >   	 * Disable the system suspend direct complete optimization.
> > > > >   	 * We need to ensure that the regular device suspend/resume functions
> > > > > @@ -366,8 +376,12 @@ int xe_pm_init(struct xe_device *xe)
> > > > >   static void xe_pm_runtime_fini(struct xe_device *xe)
> > > > >   {
> > > > > +	struct pci_dev *pdev = to_pci_dev(xe->drm.dev);
> > > > >   	struct device *dev = xe->drm.dev;
> > > > > +	if (!(pdev->pm_cap || !IS_SRIOV_VF(xe)))
> > > > > +		return;
> > > > > +
> > > > >   	pm_runtime_get_sync(dev);
> > > > >   	pm_runtime_forbid(dev);
> > > > >   }
> > > > > -- 
> > > > > 2.43.0
> > > > > 
> > > 

      reply	other threads:[~2025-08-04 16:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-01 16:30 [PATCH v3] drm/xe/pm: Disable RPM for SR-IOV VFs with no PCIe PM capability Satyanarayana K V P
2025-08-01 18:22 ` ✓ CI.KUnit: success for drm/xe/pm: Disable RPM for SR-IOV VFs with no PCIe PM capability (rev2) Patchwork
2025-08-01 19:24 ` ✓ Xe.CI.BAT: " Patchwork
2025-08-01 20:41 ` ✗ Xe.CI.Full: failure " Patchwork
2025-08-02 17:45 ` [PATCH v3] drm/xe/pm: Disable RPM for SR-IOV VFs with no PCIe PM capability Maarten Lankhorst
2025-08-04 14:51 ` Rodrigo Vivi
2025-08-04 15:00   ` K V P, Satyanarayana
2025-08-04 15:11     ` [PATCH v3] drm/xe/pm: Disable RPM for SR-IOV VFs with no PCIe PM capability] Rodrigo Vivi
2025-08-04 16:20       ` Michał Winiarski
2025-08-04 16:54         ` Rodrigo Vivi [this message]

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=aJDlvknZOh7u0Gdf@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=anshuman.gupta@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.brost@intel.com \
    --cc=michal.wajdeczko@intel.com \
    --cc=michal.winiarski@intel.com \
    --cc=satyanarayana.k.v.p@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;
as well as URLs for NNTP newsgroup(s).