On Fri, Sep 6, 2013 at 6:01 PM, Rafael J. Wysocki <rjw@xxxxxxx> 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. 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 :) Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
