From: "Limonciello, Mario" <mario.limonciello@amd.com>
To: Kai-Heng Feng <kai.heng.feng@canonical.com>,
Bjorn Helgaas <helgaas@kernel.org>
Cc: Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>,
linux-pci@vger.kernel.org,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
linux-kernel@vger.kernel.org, Vidya Sagar <vidyas@nvidia.com>,
Michael Bottini <michael.a.bottini@linux.intel.com>,
intel-wired-lan@osuosl.org, bhelgaas@google.com,
Mika Westerberg <mika.westerberg@linux.intel.com>
Subject: Re: [Intel-wired-lan] [PATCH] PCI/ASPM: Enable ASPM on external PCIe devices
Date: Mon, 17 Jul 2023 11:51:32 -0500 [thread overview]
Message-ID: <dc44cb41-b306-f18a-c9fc-3d956777f722@amd.com> (raw)
In-Reply-To: <CAAd53p42jiTCOsRZwEY0jtBejMDs1FbTOBNEknijnVNk3ENxuA@mail.gmail.com>
On 7/16/2023 10:34 PM, Kai-Heng Feng wrote:
> On Sat, Jul 15, 2023 at 12:37 AM Mario Limonciello
> <mario.limonciello@amd.com> wrote:
>>
>> On 7/14/23 03:17, Kai-Heng Feng wrote:
>>> On Thu, Jul 6, 2023 at 12:07 PM Mario Limonciello
>>> <mario.limonciello@amd.com> wrote:
>>>>
>>>> On 7/5/23 15:06, Bjorn Helgaas wrote:
>>>>> On Wed, Jun 28, 2023 at 01:09:49PM +0800, Kai-Heng Feng wrote:
>>>>>> On Wed, Jun 28, 2023 at 4:54 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
>>>>>>> On Tue, Jun 27, 2023 at 04:35:25PM +0800, Kai-Heng Feng wrote:
>>>>>>>> On Fri, Jun 23, 2023 at 7:06 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
>>>>>>>>> On Tue, Jun 20, 2023 at 01:36:59PM -0500, Limonciello, Mario wrote:
>>>>>
>>>>>>> It's perfectly fine for the IP to support PCI features that are not
>>>>>>> and can not be enabled in a system design. But I expect that
>>>>>>> strapping or firmware would disable those features so they are not
>>>>>>> advertised in config space.
>>>>>>>
>>>>>>> If BIOS leaves features disabled because they cannot work, but at the
>>>>>>> same time leaves them advertised in config space, I'd say that's a
>>>>>>> BIOS defect. In that case, we should have a DMI quirk or something to
>>>>>>> work around the defect.
>>>>>>
>>>>>> That means most if not all BIOS are defected.
>>>>>> BIOS vendors and ODM never bothered (and probably will not) to change
>>>>>> the capabilities advertised by config space because "it already works
>>>>>> under Windows".
>>>>>
>>>>> This is what seems strange to me. Are you saying that Windows never
>>>>> enables these power-saving features? Or that Windows includes quirks
>>>>> for all these broken BIOSes? Neither idea seems very convincing.
>>>>>
>>>>
>>>> I see your point. I was looking through Microsoft documentation for
>>>> hints and came across this:
>>>>
>>>> https://learn.microsoft.com/en-us/windows-hardware/customize/power-settings/pci-express-settings-link-state-power-management
>>>>
>>>> They have a policy knob to globally set L0 or L1 for PCIe links.
>>>>
>>>> They don't explicitly say it, but surely it's based on what the devices
>>>> advertise in the capabilities registers.
>>>
>>> So essentially it can be achieved via boot time kernel parameter
>>> and/or sysfs knob.
>>>
>>> The main point is OS should stick to the BIOS default, which is the
>>> only ASPM setting tested before putting hardware to the market.
>>
>> Unfortunately; I don't think you can jump to this conclusion.
>>
>> A big difference in the Windows world to Linux world is that OEMs ship
>> with a factory Windows image that may set policies like this. OEM
>> "platform" drivers can set registry keys too.
>
> Thanks. This is new to me.
>
>>
>> I think the next ASPM issue that comes up what we (collectively) need to
>> do is compare ASPM policy and PCI registers for:
>> 1) A "clean" Windows install from Microsoft media before all the OEM
>> drivers are installed.
>> 2) A Windows install that the drivers have been installed.
>> 3) A up to date mainline Linux kernel.
>>
>> Actually as this thread started for determining policy for external PCIe
>> devices, maybe that would be good to check with those.
>
> Did that before submitting the patch.
> From very limited devices I tested, ASPM is enabled for external
> connected PCIe device via TBT ports.
>
> I wonder if there's any particular modification should be improved for
> this patch?
>
Knowing this information I personally think the original patch that
started this thread makes a lot of sense.
Bjorn, what are your thoughts?
> Kai-Heng
>
>>
>>>
>>> Kai-Heng
>>>
>>>>
>>>>>>>> So the logic is to ignore the capability and trust the default set
>>>>>>>> by BIOS.
>>>>>>>
>>>>>>> I think limiting ASPM support to whatever BIOS configured at boot-time
>>>>>>> is problematic. I don't think we can assume that all platforms have
>>>>>>> firmware that configures ASPM as aggressively as possible, and
>>>>>>> obviously firmware won't configure hot-added devices at all (in
>>>>>>> general; I know ACPI _HPX can do some of that).
>>>>>>
>>>>>> Totally agree. I was not suggesting to limiting the setting at all.
>>>>>> A boot-time parameter to flip ASPM setting is very useful. If none has
>>>>>> been set, default to BIOS setting.
>>>>>
>>>>> A boot-time parameter for debugging and workarounds is fine. IMO,
>>>>> needing a boot-time parameter in the course of normal operation is
>>>>> not OK.
>>>>>
>>>>> Bjorn
>>>>
>>
next prev parent reply other threads:[~2023-07-17 16:51 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
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 [this message]
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=dc44cb41-b306-f18a-c9fc-3d956777f722@amd.com \
--to=mario.limonciello@amd.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=intel-wired-lan@osuosl.org \
--cc=kai.heng.feng@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--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).