From: Bjorn Helgaas <helgaas@kernel.org>
To: "Gupta, Anshuman" <anshuman.gupta@intel.com>
Cc: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"rafael@kernel.org" <rafael@kernel.org>,
"lenb@kernel.org" <lenb@kernel.org>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"ilpo.jarvinen@linux.intel.com" <ilpo.jarvinen@linux.intel.com>,
"De Marchi, Lucas" <lucas.demarchi@intel.com>,
"Vivi, Rodrigo" <rodrigo.vivi@intel.com>,
"Nilawar, Badal" <badal.nilawar@intel.com>,
"Nasim, Kam" <kam.nasim@intel.com>,
"Gupta, Varun" <varun.gupta@intel.com>
Subject: Re: [RFC 1/6] PCI/ACPI: Implement PCI FW _DSM method
Date: Tue, 25 Feb 2025 14:30:24 -0600 [thread overview]
Message-ID: <20250225203024.GA516174@bhelgaas> (raw)
In-Reply-To: <CY5PR11MB62113F649A1AF98D33ACE0AC95C32@CY5PR11MB6211.namprd11.prod.outlook.com>
On Tue, Feb 25, 2025 at 06:25:52PM +0000, Gupta, Anshuman wrote:
> > -----Original Message-----
> > From: Bjorn Helgaas <helgaas@kernel.org>
> ... redundant headers snipped
> > On Mon, Feb 24, 2025 at 10:18:44PM +0530, Anshuman Gupta wrote:
> > > Implement _DSM method 10 and _DSM Method 11 as per PCI firmware
> > specs
> > > section 4.6.10 and 4.6.11.
> >
> > Please split into two patches, one for each _DSM. Include spec
> > citations, e.g., PCI Firmware r3.3, sec 4.6.10. Section numbers
> > are not guaranteed to stay consistent across spec revisions, so we
> > need both the revision and section number.
> >
> > Include some descriptive words about the DSM in each subject line,
> > e.g., "D3cold Aux Power Limit", "PERST# Assertion Delay".
> >
> > > Current assumption is only one PCIe Endpoint driver (XeKMD for
> > > Battlemage GPU) will request for Aux Power Limit under a given Root
> > > Port but theoretically it is possible that other Non-Intel GPU or
> > > Non-GPU PCIe Endpoint driver can also request for Aux Power Limit and
> > > request to block the core power removal under same Root Port.
> > > That will disrupt the Battlemage GPU VRAM Self Refresh.
> >
> > I guess this is sort of an acknowledgement of the r3.3, sec 4.6.10 spec text
> > about system software being responsible for tracking and aggregating
> > requests when there are multiple functions below the Downstream Port?
> AFAIU apart from multiple function below the Downstream Port (from
> same PCIe Card), there can be possibility of another PCie card
> connected via a switch to same root port like below topology.
>
> |-> PCIe PCIe Downstream Port -> End Point Device
> Root Port -> PCIe Upstream Port |-> PCIe PCIe Downstream Port -> End Point Device
> |-> PCIe PCIe Downstream Port -> PCIe Upstream Port -> PCIe Downstream Port -> *EndPoint Device
>
> *Endpoint Device from different PCIe card can also request to block the core power removal under same Root Port ?
Of course.
> How to document such limitation ?
> > If so, remove the Battlemage-specific language and just say something about
> > the fact that this implementation doesn't do any of that tracking and
> > aggregation.
^^ Here's a hint about how to document this. My point is that this
has nothing to do with Battlemage in particular, so the text about
Battlemage-specific things is a distraction from the real point, which
IIUC is this:
Note that this implementation assumes only a single device below the
Downstream Port because it does not track and aggregate requests
from all child devices below the Downstream Port as required by sec
4.6.10.
> > > One possible mitigation would be only allowing only first PCIe
> > > Non-Bridge Endpoint Function 0 driver to call_DSM method 10.
next prev parent reply other threads:[~2025-02-25 20:30 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-24 16:48 [RFC 0/6] VRAM Self Refresh Anshuman Gupta
2025-02-24 16:48 ` [RFC 1/6] PCI/ACPI: Implement PCI FW _DSM method Anshuman Gupta
2025-02-24 19:40 ` Bjorn Helgaas
2025-02-25 18:25 ` Gupta, Anshuman
2025-02-25 20:30 ` Bjorn Helgaas [this message]
2025-02-24 16:48 ` [RFC 2/6] drm/xe/vrsr: Detect vrsr capability Anshuman Gupta
2025-03-07 21:50 ` Rodrigo Vivi
2025-02-24 16:48 ` [RFC 3/6] drm/xe/vrsr: Apis to init and enable VRSR feature Anshuman Gupta
2025-02-24 19:43 ` Bjorn Helgaas
2025-03-10 17:23 ` Rodrigo Vivi
2025-02-24 16:48 ` [RFC 4/6] drm/xe/vrsr: Refactor d3cold.allowed to a enum Anshuman Gupta
2025-03-10 17:28 ` Rodrigo Vivi
2025-04-01 5:24 ` Poosa, Karthik
2025-02-24 16:48 ` [RFC 5/6] drm/xe/pm: D3Cold target state Anshuman Gupta
2025-02-24 19:45 ` Bjorn Helgaas
2025-02-25 17:49 ` Ville Syrjälä
2025-02-25 18:00 ` Gupta, Anshuman
2025-02-25 18:44 ` Ville Syrjälä
2025-02-24 16:48 ` [RFC 6/6] drm/xe/vrsr: Enable VRSR Anshuman Gupta
2025-04-01 5:19 ` [RFC,6/6] " Poosa, Karthik
2025-02-25 0:07 ` ✓ CI.Patch_applied: success for VRAM Self Refresh Patchwork
2025-02-25 0:08 ` ✗ CI.checkpatch: warning " Patchwork
2025-02-25 0:08 ` ✗ CI.KUnit: failure " 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=20250225203024.GA516174@bhelgaas \
--to=helgaas@kernel.org \
--cc=anshuman.gupta@intel.com \
--cc=badal.nilawar@intel.com \
--cc=bhelgaas@google.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=kam.nasim@intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lucas.demarchi@intel.com \
--cc=rafael@kernel.org \
--cc=rodrigo.vivi@intel.com \
--cc=varun.gupta@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