(2011/03/18 13:21), Naga Chumbalkar wrote:
v2 -> v1: . Kept the logic in pci_raw_set_power_state . Changed the ASPM enabling logic . Modified the text that describes the problem v1 : http://marc.info/?l=linux-pci&m=130013164703283&w=2 The assumption made in commit 41cd766b065970ff6f6c89dd1cf55fa706c84a3d (PCI: Don't enable aspm before drivers have had a chance to veto it) that pci_enable_device() will result in re-configuring ASPM when aspm_policy is POWERSAVE is no longer valid. This is due to commit 97c145f7c87453cec90e91238fba5fe2c1561b32 (PCI: read current power state at enable time) which resets dev->current_state to D0. This makes the equality check (below) become true, so pcie_aspm_pm_state_change() never gets called. ./drivers/pci/pci.c: pci_raw_set_pci_power_state() 546 /* Check if we're already there */ 547 if (dev->current_state == state) 548 return 0; So OSPM doesnn't configure the PCIe links for ASPM. The patch below does the following: At the end of each Root Bridge scan make a call to configure ASPM when the ASPM policy is set to "powersave" mode. Note that if a previous pass had completed the configuration for all devices under that Bridge then the configuration will not take place again because pcie_config_aspm_link() checks to see if the link is already in the requested state. We won't reconfigure ASPM when _OSC control is not granted.
Which _OSC controls do we need for configuring ASPM? Regards, Kenji Kaneshige -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
