From: Bjorn Helgaas <helgaas@kernel.org>
To: Om Prakash Singh <omp@nvidia.com>
Cc: hemantk@codeaurora.org, bhelgaas@google.com,
manivannan.sadhasivam@linaro.org, bjorn.andersson@linaro.org,
linux-pci@vger.kernel.org, Vidya Sagar <vidyas@nvidia.com>
Subject: Re: Query on ASPM driver design
Date: Tue, 27 Jul 2021 10:18:16 -0500 [thread overview]
Message-ID: <20210727151816.GA714116@bjorn-Precision-5520> (raw)
In-Reply-To: <28465f90-3c64-678a-9b90-209eaa30a084@nvidia.com>
On Tue, Jul 27, 2021 at 07:51:37AM +0530, Om Prakash Singh wrote:
> Hi Bjorn,
> I think it makes sense to have the scope of keeping default ASPM
> policy disable and API pci_enable_link_state() to selectively enable
> by EP Driver.
>
> sysfs interface for ASPM also does not allow enabling ASPM for a
> device if the default policy (policy_to_aspm_state()) does not allow
> it.
The ASPM policy implementation may require changes. I think the
current setup where a policy is compiled into the kernel via Kconfig
options is seriously flawed.
We need a fail-safe kernel parameter, i.e., "pcie_aspm=off", for cases
where devices don't work at all with ASPM. We need quirks to work
around devices known to be broken, e.g., those that advertise ASPM
support that doesn't actually work, or those that advertise incorrect
exit latencies. I think most other configuration should be done via
sysfs.
> Consider a situation, for a platform one wants to utilize ASPM
> capability of an onboard PCIe device because it is well evaluated,
> at the same time they want to keep ASPM disabled for other PCIe
> devices that can be connected on open PCIe slot to avoid possible
> performance issue.
>
> I see ASPM is broken on many devices, though the device shows ASPM
> capabilities but has performance issues when it is enabled.
I'll wait to see your proposal and use case before commenting on this.
Bjorn
next prev parent reply other threads:[~2021-07-27 15:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210723203206.GA436727@bjorn-Precision-5520>
2021-07-23 22:04 ` Query on ASPM driver design hemantk
2021-07-23 22:28 ` Bjorn Helgaas
2021-07-27 2:21 ` Om Prakash Singh
2021-07-27 15:18 ` Bjorn Helgaas [this message]
2021-07-28 1:18 ` Om Prakash Singh
2021-07-28 16:01 ` Bjorn Helgaas
2021-07-29 2:35 ` Om Prakash Singh
2021-07-30 6:07 ` Om Prakash Singh
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=20210727151816.GA714116@bjorn-Precision-5520 \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=bjorn.andersson@linaro.org \
--cc=hemantk@codeaurora.org \
--cc=linux-pci@vger.kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=omp@nvidia.com \
--cc=vidyas@nvidia.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