From: Josef Bacik <jbacik@fb.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: <linux-pci@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-acpi@vger.kernel.org>, <bhelgaas@google.com>,
<shli@fb.com>, <kernel-team@fb.com>,
Matthew Garrett <mjg59@coreos.com>
Subject: Re: [PATCH] pci: completely disable aspm if it's unsupported
Date: Wed, 18 Nov 2015 14:00:18 -0500 [thread overview]
Message-ID: <564CCAC2.5050600@fb.com> (raw)
In-Reply-To: <20151118184038.GA4462@localhost>
On 11/18/2015 01:40 PM, Bjorn Helgaas wrote:
> [+cc Matthew]
>
> Hi Josef,
>
> On Wed, Nov 18, 2015 at 09:25:03AM -0500, Josef Bacik wrote:
>> We have some hardware that takes about 30 seconds to setup common clocks for
>> ASPM, but our bios'es don't actually allow ASPM. It seems we had this thing in
>> place where we would disable ASPM after the pci bus probe so that we would make
>> sure that pre pcie 1.1 devices would be properly skipped during initialization.
>> This is because the mechanism to disable ASPM doesn't actually disable the
>> setting up of the link state stuff, it just keeps us from changing the link
>> state after the fact. So instead make it so that when we call pcie_no_aspm()
>> that we disable ASPM completley, that is we skip setting up the link state and
>> everything. This way we avoid the costly setup for a feature we cannot support
>> in the first place and we also make sure we are safe from future tampering with
>> the ASPM link state. Thanks,
>
> Can you clarify what your BIOS does? I assume it's an x86 ACPI BIOS.
> Does it enable ASPM before handing off to the OS? Does it set the
> ACPI_FADT_NO_ASPM bit? (ACPI spec 5.0, sec 5.2.9.3)
>
> You're changing the _OSC failure path. Why does _OSC fail? I know
> there is some sort of unresolved problem there
> (https://bugzilla.kernel.org/show_bug.cgi?id=94661); maybe you're
> tripping over that?
>
This is what I see in dmesg
[ 8.647398] acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM
ClockPM Segments MSI]
[ 8.647716] acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM
So seems like the same bug?
> It seems like you're proposing to reverse what Matthew just did with
> 387d37577fdd ("PCI: Don't clear ASPM bits when the FADT declares it's
> unsupported").
>
It looks to me I'm doing what Matthew set out to do, only with a bigger
hammer ;). His patch still allowed the initialization of the ASPM
stuff, like setting up the clocks and such, but then made it so we
couldn't change the ASPM state at all. My patch goes the step further
of not even doing the initialization stuff. Thanks,
Josef
next prev parent reply other threads:[~2015-11-18 19:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-18 14:25 [PATCH] pci: completely disable aspm if it's unsupported Josef Bacik
2015-11-18 18:40 ` Bjorn Helgaas
2015-11-18 19:00 ` Josef Bacik [this message]
2015-11-18 19:19 ` Matthew Garrett
2015-12-03 16:40 ` Bjorn Helgaas
2015-12-03 22:40 ` Pavel Machek
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=564CCAC2.5050600@fb.com \
--to=jbacik@fb.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=kernel-team@fb.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mjg59@coreos.com \
--cc=shli@fb.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).