public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "David E. Box" <david.e.box@linux.intel.com>
To: Bjorn Helgaas <helgaas@kernel.org>, puranjay12@gmail.com
Cc: Jian-Hong Pan <jhp@endlessos.org>,
	Johan Hovold <johan@kernel.org>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Damien Le Moal <dlemoal@kernel.org>,
	Niklas Cassel <cassel@kernel.org>,
	Nirmal Patel <nirmal.patel@linux.intel.com>,
	Jonathan Derrick <jonathan.derrick@linux.dev>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	 linux@endlessos.org
Subject: Re: [PATCH v2] PCI: vmd: Enable PCI PM's L1 substates of remapped PCIe Root Port and NVMe
Date: Tue, 06 Feb 2024 13:25:29 -0800	[thread overview]
Message-ID: <9cfc65c594deef33f24b60a66b7c78c742da7203.camel@linux.intel.com> (raw)
In-Reply-To: <02938148545933dc9865ddbc5551e3e8a579d57e.camel@linux.intel.com>

Adding Puranjay

On Mon, 2024-02-05 at 15:05 -0800, David E. Box wrote:
> On Mon, 2024-02-05 at 16:42 -0600, Bjorn Helgaas wrote:
> > On Mon, Feb 05, 2024 at 11:37:16AM -0800, David E. Box wrote:
> > > On Fri, 2024-02-02 at 18:05 -0600, Bjorn Helgaas wrote:
> > > > On Fri, Feb 02, 2024 at 03:11:12PM +0800, Jian-Hong Pan wrote:
> > > ...
> > 
> > > > > @@ -775,6 +773,14 @@ static int vmd_pm_enable_quirk(struct pci_dev
> > > > > *pdev,
> > > > > void *userdata)
> > > > >         pci_write_config_dword(pdev, pos + PCI_LTR_MAX_SNOOP_LAT,
> > > > > ltr_reg);
> > > > >         pci_info(pdev, "VMD: Default LTR value set by driver\n");
> > > > 
> > > > You're not changing this part, and I don't understand exactly how LTR
> > > > works, but it makes me a little bit queasy to read "set the LTR value
> > > > to the maximum required to allow the deepest power management
> > > > savings" and then we set the max snoop values to a fixed constant.
> > > > 
> > > > I don't think the goal is to "allow the deepest power savings"; I
> > > > think it's to enable L1.2 *when the device has enough buffering to
> > > > absorb L1.2 entry/exit latencies*.
> > > > 
> > > > The spec (PCIe r6.0, sec 7.8.2.2) says "Software should set this to
> > > > the platform's maximum supported latency or less," so it seems like
> > > > that value must be platform-dependent, not fixed.
> > > > 
> > > > And I assume the "_DSM for Latency Tolerance Reporting" is part of the
> > > > way to get those platform-dependent values, but Linux doesn't actually
> > > > use that yet.
> > > 
> > > This may indeed be the best way but we need to double check with our
> > > BIOS folks.  AFAIK BIOS writes the LTR values directly so there
> > > hasn't been a need to use this _DSM. But under VMD the ports are
> > > hidden from BIOS which is why we added it here. I've brought up the
> > > question internally to find out how Windows handles the DSM and to
> > > get a recommendation from our firmware leads.
> > 
> > We want Linux to be able to program LTR itself, don't we?  We
> > shouldn't have to rely on firmware to do it.  If Linux can't do
> > it, hot-added devices aren't going to be able to use L1.2, right?
> 
> Agreed. We just want to make sure we are not conflicting with what BIOS may be
> doing.

So the feedback is to run the _DSM and just overwrite any BIOS values. Looking
up the _DSM I saw there was an attempt to upstream this 4 years ago [1]. I'm not
sure why the effort stalled but we can pick up this work again.

https://patchwork.kernel.org/project/linux-pci/patch/20201015080311.7811-1-puranjay12@gmail.com/

  reply	other threads:[~2024-02-06 21:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-02  7:11 [PATCH v2] PCI: vmd: Enable PCI PM's L1 substates of remapped PCIe Root Port and NVMe Jian-Hong Pan
2024-02-03  0:05 ` Bjorn Helgaas
2024-02-05 19:37   ` David E. Box
2024-02-05 22:42     ` Bjorn Helgaas
2024-02-05 23:05       ` David E. Box
2024-02-06 21:25         ` David E. Box [this message]
2024-02-06 23:30           ` Bjorn Helgaas
2024-02-07 19:51             ` David E. Box
2024-02-06 12:29 ` Ilpo Järvinen
2024-02-06 16:00   ` Bjorn Helgaas

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=9cfc65c594deef33f24b60a66b7c78c742da7203.camel@linux.intel.com \
    --to=david.e.box@linux.intel.com \
    --cc=cassel@kernel.org \
    --cc=dlemoal@kernel.org \
    --cc=helgaas@kernel.org \
    --cc=jhp@endlessos.org \
    --cc=johan@kernel.org \
    --cc=jonathan.derrick@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux@endlessos.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=nirmal.patel@linux.intel.com \
    --cc=puranjay12@gmail.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