linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robert Hancock <hancockrwd@gmail.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	Len Brown <lenb@kernel.org>,
	Matthew Garrett <mjg59@srcf.ucam.org>
Subject: Re: [PATCH 00/14] _OSC simplification
Date: Wed, 25 Sep 2013 00:52:26 -0600	[thread overview]
Message-ID: <5242882A.5090401@gmail.com> (raw)
In-Reply-To: <CAErSpo4YRS3-EC5NcFVyi-yBbEX2Fmr0G=Vt2pk_SO7+5Ad91A@mail.gmail.com>

On 09/07/2013 07:59 AM, Bjorn Helgaas wrote:
> On Fri, Sep 6, 2013 at 6:01 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> On Friday, September 06, 2013 11:13:24 AM Bjorn Helgaas wrote:
>>> This is a long series of mostly minor changes with the goal of
>>> simplifying the _OSC-related code and making the negotiation between
>>> Linux and the platform more understandable.
>>>
>>> My intent is that this doesn't change any behavior except for the text
>>> in dmesg.
>>>
>>> However, this restructuring does raise some questions in my mind, such
>>> as the fact that we do not call pcie_no_aspm() to disable ASPM in two
>>> cases where it seems like we might want to:
>>>
>>>    1) When pcie_ports_disabled, e.g., when booting with
>>>       "pcie_ports=compat".
>>>
>>>    2) When Linux doesn't support all the required services, e.g., if
>>>       compiled with ASPM support but not MSI support.
>>
>> We tried that (i.e. 2)), but then it caused energy usage to increase on some
>> systems with power-hungry graphics adapters and Phoronix made some fuss about
>> that. :-)
>
> The _OSC section of the spec is pretty obtuse, but my reading of Table
> 4-6 (PCI Firmware r3.0) is that the OS is prohibited from writing to
> the PCIe Capability (for ASPM, VC, AER, or other control) unless it
> has been granted "PCI Express Capability Structure control".  That's
> why I'm dubious about the fact that we use ASPM in those two cases
> where we don't even *ask* for that control.

AFAIK, I believe the problem was that in cases where we decided that 
ASPM shouldn't be used (such as if the FADT flag for "don't enable ASPM" 
was set), the kernel was explicitly disabling ASPM for devices even if 
the BIOS had turned it on. This caused a power regression compared to 
Windows which left ASPM enabled on those devices. I believe this was 
later changed to treat this case as "don't touch ASPM settings" rather 
than "force ASPM off on everything".

I'm not sure that all kernel messages have been updated to reflect this, 
though - there seem to be some cases where we confusingly say "disabling 
ASPM" when what it should likely say "disabling ASPM control".

>
> For the Phoronix case, I assume they made the argument that Windows
> does use ASPM without having PCIe Capability control?  Do you have any
> pointers to that discussion?
>
> I don't propose changing this now, but it does raise my eyebrows.
> Maybe some sort of dmesg note would be appropriate.
>
> Thanks for looking at all this stuff; I know from experience that it's
> pretty hard to wade through :)


  parent reply	other threads:[~2013-09-25  6:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-06 17:13 [PATCH 00/14] _OSC simplification Bjorn Helgaas
2013-09-06 17:13 ` [PATCH 01/14] ACPI: Write _OSC bit field definitions in hex Bjorn Helgaas
2013-09-06 17:13 ` [PATCH 02/14] ACPI: Rename OSC_QUERY_TYPE to OSC_QUERY_DWORD Bjorn Helgaas
2013-09-06 17:13 ` [PATCH 03/14] ACPI: Tidy acpi_run_osc() declarations Bjorn Helgaas
2013-09-06 17:13 ` [PATCH 04/14] ACPI: Remove unused OSC_PCI_NATIVE_HOTPLUG Bjorn Helgaas
2013-09-06 17:14 ` [PATCH 05/14] ACPI: Write OSC_PCI_CONTROL_MASKS like OSC_PCI_SUPPORT_MASKS Bjorn Helgaas
2013-09-06 17:14 ` [PATCH 06/14] PCI/ACPI: Name _OSC #defines more consistently Bjorn Helgaas
2013-09-06 17:14 ` [PATCH 07/14] PCI/ACPI: Drop unnecessary _OSC existence tests Bjorn Helgaas
2013-09-06 17:14 ` [PATCH 08/14] PCI/ACPI: Move _OSC stuff from acpi_pci_root_add() to negotiate_os_control() Bjorn Helgaas
2013-09-06 17:14 ` [PATCH 09/14] PCI/ACPI: Split _OSC "support" and "control" flags into separate variables Bjorn Helgaas
2013-09-06 17:14 ` [PATCH 10/14] PCI/ACPI: Run _OSC only once for OSPM feature support Bjorn Helgaas
2013-09-06 17:14 ` [PATCH 11/14] PCI/ACPI: Skip _OSC control tests if _OSC support call failed Bjorn Helgaas
2013-09-06 17:14 ` [PATCH 12/14] PCI/ACPI: Separate out _OSC "PCIe port services disabled" path Bjorn Helgaas
2013-09-06 17:15 ` [PATCH 13/14] PCI/ACPI: Separate out _OSC "we don't support enough services" path Bjorn Helgaas
2013-09-06 17:15 ` [PATCH 14/14] PCI/ACPI: Decode _OSC bitmasks symbolically Bjorn Helgaas
2013-09-07  0:01 ` [PATCH 00/14] _OSC simplification Rafael J. Wysocki
2013-09-07 13:59   ` Bjorn Helgaas
2013-09-07 22:05     ` Rafael J. Wysocki
2013-09-25  6:52     ` Robert Hancock [this message]
2013-09-07  0:08 ` Rafael J. Wysocki

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=5242882A.5090401@gmail.com \
    --to=hancockrwd@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=rjw@sisk.pl \
    /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).