linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: bhelgaas@google.com,
	Mario Limonciello <mario.limonciello@amd.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Kuppuswamy Sathyanarayanan 
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	Vidya Sagar <vidyas@nvidia.com>,
	Michael Bottini <michael.a.bottini@linux.intel.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PCI/ASPM: Enable ASPM on external PCIe devices
Date: Thu, 15 Jun 2023 12:12:29 -0500	[thread overview]
Message-ID: <20230615171229.GA1478685@bhelgaas> (raw)
In-Reply-To: <20230615070421.1704133-1-kai.heng.feng@canonical.com>

On Thu, Jun 15, 2023 at 03:04:20PM +0800, Kai-Heng Feng wrote:
> When a PCIe device is hotplugged to a Thunderbolt port, ASPM is not
> enabled for that device. However, when the device is plugged preboot,
> ASPM is enabled by default.
> 
> The disparity happens because BIOS doesn't have the ability to program
> ASPM on hotplugged devices.
> 
> So enable ASPM by default for external connected PCIe devices so ASPM
> settings are consitent between preboot and hotplugged.
> 
> On HP Thunderbolt Dock G4, enable ASPM can also fix BadDLLP error:
> pcieport 0000:00:1d.0: AER: Corrected error received: 0000:07:04.0
> pcieport 0000:07:04.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID)
> pcieport 0000:07:04.0:   device [8086:0b26] error status/mask=00000080/00002000
> pcieport 0000:07:04.0:    [ 7] BadDLLP
> 
> The root cause is still unclear, but quite likely because the I225 on
> the dock supports PTM, where ASPM timing is precalculated for the PTM.
> 
> Cc: Mario Limonciello <mario.limonciello@amd.com>
> Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217557
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> ---
>  drivers/pci/pcie/aspm.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
> index 66d7514ca111..613b0754c9bb 100644
> --- a/drivers/pci/pcie/aspm.c
> +++ b/drivers/pci/pcie/aspm.c
> @@ -119,7 +119,9 @@ static int policy_to_aspm_state(struct pcie_link_state *link)
>  		/* Enable Everything */
>  		return ASPM_STATE_ALL;
>  	case POLICY_DEFAULT:
> -		return link->aspm_default;
> +		return dev_is_removable(&link->downstream->dev) ?
> +			link->aspm_capable :
> +			link->aspm_default;

I'm a little hesitant because dev_is_removable() is a convenient test
that covers the current issue, but it doesn't seem tightly connected
from a PCIe architecture perspective.

I think the current model of compile-time ASPM policy selection:

  CONFIG_PCIEASPM_DEFAULT          /* BIOS default setting */
  CONFIG_PCIEASPM_PERFORMANCE      /* disable L0s and L1 */
  CONFIG_PCIEASPM_POWERSAVE        /* enable L0s and L1 */
  CONFIG_PCIEASPM_POWER_SUPERSAVE  /* enable L1 substates */

is flawed.  As far as I know, there's no technical reason we have to
select this at kernel build-time.  I suspect the original reason was
risk avoidance, i.e., we were worried that we might expose hardware
defects if we enabled ASPM states that BIOS hadn't already enabled.

How do we get out of that model?  We do have sysfs knobs that should
cover all the functionality (set overall policy as above via
/sys/module/pcie_aspm/parameters/policy; set device-level exceptions
via /sys/bus/pci/devices/.../link/*_aspm).

In my opinion, the cleanest solution would be to enable all ASPM
functionality whenever possible and let users disable it if they need
to for performance.  If there are device defects when something is
enabled, deal with it via quirks, as we do for other PCI features.

That feels a little risky, but let's have a conversation about where
we want to go in the long term.  It's good to avoid risk, but too much
avoidance leads to its own complexity and an inability to change
things.

Bjorn

  parent reply	other threads:[~2023-06-15 17:12 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-15  7:04 [PATCH] PCI/ASPM: Enable ASPM on external PCIe devices Kai-Heng Feng
2023-06-15 14:02 ` Ilpo Järvinen
2023-06-15 17:07 ` Sathyanarayanan Kuppuswamy
2023-06-16  2:37   ` Kai-Heng Feng
2023-06-15 17:12 ` Bjorn Helgaas [this message]
2023-06-16  3:01   ` Kai-Heng Feng
2023-06-19 16:16     ` Limonciello, Mario
2023-06-19 21:37       ` Bjorn Helgaas
2023-06-19 22:09         ` Limonciello, Mario
2023-06-20 18:28           ` Bjorn Helgaas
2023-06-20 18:36             ` Limonciello, Mario
2023-06-22 23:06               ` Bjorn Helgaas
2023-06-27  8:35                 ` Kai-Heng Feng
2023-06-27 20:54                   ` Bjorn Helgaas
2023-06-28  5:09                     ` Kai-Heng Feng
2023-07-05 20:06                       ` [Intel-wired-lan] " Bjorn Helgaas
2023-07-06  4:07                         ` Mario Limonciello
2023-07-14  8:17                           ` Kai-Heng Feng
2023-07-14 16:37                             ` Mario Limonciello
2023-07-17  3:34                               ` Kai-Heng Feng
2023-07-17 16:51                                 ` Limonciello, Mario
2023-07-18 19:24                                   ` Bjorn Helgaas
2023-08-11  8:34                                     ` Kai-Heng Feng
2023-06-16 22:01 ` Bjorn Helgaas
2023-06-21  3:08   ` Kai-Heng Feng

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=20230615171229.GA1478685@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=kai.heng.feng@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=michael.a.bottini@linux.intel.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.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;
as well as URLs for NNTP newsgroup(s).