aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/pci/pci-acpi.c
Commit message (Collapse)AuthorAgeFilesLines
* PCI: Rework ASPM disable codeMatthew Garrett2012-02-061-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 3c076351c4027a56d5005a39a0b518a4ba393ce2 upstream. Right now we forcibly clear ASPM state on all devices if the BIOS indicates that the feature isn't supported. Based on the Microsoft presentation "PCI Express In Depth for Windows Vista and Beyond", I'm starting to think that this may be an error. The implication is that unless the platform grants full control via _OSC, Windows will not touch any PCIe features - including ASPM. In that case clearing ASPM state would be an error unless the platform has granted us that control. This patch reworks the ASPM disabling code such that the actual clearing of state is triggered by a successful handoff of PCIe control to the OS. The general ASPM code undergoes some changes in order to ensure that the ability to clear the bits isn't overridden by ASPM having already been disabled. Further, this theoretically now allows for situations where only a subset of PCIe roots hand over control, leaving the others in the BIOS state. It's difficult to know for sure that this is the right thing to do - there's zero public documentation on the interaction between all of these components. But enough vendors enable ASPM on platforms and then set this bit that it seems likely that they're expecting the OS to leave them alone. Measured to save around 5W on an idle Thinkpad X220. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ACPI: Add D3 cold stateLin Ming2011-05-291-0/+2
| | | | | | | | | | | | | | _SxW returns an Integer containing the lowest D-state supported in state Sx. If OSPM has not indicated that it supports _PR3, then the value “3” corresponds to D3. If it has indicated _PR3 support, the value “3” represents D3hot and the value “4” represents D3cold. Linux does set _OSC._PR3, so we should fix it to expect that _SxW can return 4. Signed-off-by: Lin Ming <ming.m.lin@intel.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: Remove the wakeup.run_wake_count device fieldRafael J. Wysocki2011-02-241-12/+4
| | | | | | | | | | | | | | | | | | The wakeup.run_wake_count ACPI device field is only used by the PCI runtime PM code to "protect" devices from being prepared for generating wakeup signals more than once in a row. However, it really doesn't provide any protection, because (1) all of the functions it is supposed to protect use their own reference counters effectively ensuring that the device will be set up for generating wakeup signals just once and (2) the PCI runtime PM code uses wakeup.run_wake_count in a racy way, since nothing prevents acpi_dev_run_wake() from being called concurrently from two different threads for the same device. Remove the wakeup.run_wake_count ACPI device field which is unnecessary, confusing and used in a wrong way. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
* PCI/PM: Report wakeup events before resuming devicesRafael J. Wysocki2011-01-141-1/+1
| | | | | | | | | Make wakeup events be reported by the PCI subsystem before attempting to resume devices or queuing up runtime resume requests for them, because wakeup events should be reported as soon as they have been detected. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Disable ASPM if BIOS asks us toMatthew Garrett2010-12-231-0/+1
| | | | | | | | | | | | | We currently refuse to touch the ASPM registers if the BIOS tells us that ASPM isn't supported. This can cause problems if the BIOS has (for any reason) enabled ASPM on some devices anyway. Change the code such that we explicitly clear ASPM if the FADT indicates that ASPM isn't supported, and make sure we tidy up appropriately on device removal in order to deal with the hotplug case. If ASPM is disabled because the BIOS doesn't hand over control then we won't touch the registers. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* Merge branch 'acpica' of ↵Linus Torvalds2010-08-071-4/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 * 'acpica' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (27 commits) ACPI / ACPICA: Simplify acpi_ev_initialize_gpe_block() ACPI / ACPICA: Fail acpi_gpe_wakeup() if ACPI_GPE_CAN_WAKE is unset ACPI / ACPICA: Do not execute _PRW methods during initialization ACPI: Fix bogus GPE test in acpi_bus_set_run_wake_flags() ACPICA: Update version to 20100702 ACPICA: Fix for Alias references within Package objects ACPICA: Fix lint warning for 64-bit constant ACPICA: Remove obsolete GPE function ACPICA: Update debug output components ACPICA: Add support for WDDT - Watchdog Descriptor Table ACPICA: Drop acpi_set_gpe ACPICA: Use low-level GPE enable during GPE block initialization ACPI / EC: Do not use acpi_set_gpe ACPI / EC: Drop suspend and resume routines ACPICA: Remove wakeup GPE reference counting which is not used ACPICA: Introduce acpi_gpe_wakeup() ACPICA: Rename acpi_hw_gpe_register_bit ACPICA: Update version to 20100528 ACPICA: Add signatures for undefined tables: ATKG, GSCI, IEIT ACPICA: Optimization: Reduce the number of namespace walks ...
| * ACPICA: Remove wakeup GPE reference counting which is not usedRafael J. Wysocki2010-07-061-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After the previous patch that introduced acpi_gpe_wakeup() and modified the ACPI suspend and wakeup code to use it, the third argument of acpi_{enable|disable}_gpe() and the GPE wakeup reference counter are not necessary any more. Remove them and modify all of the users of acpi_{enable|disable}_gpe() accordingly. Also drop GPE type constants that aren't used any more. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | PM: Make it possible to avoid races between wakeup and system sleepRafael J. Wysocki2010-07-191-0/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One of the arguments during the suspend blockers discussion was that the mainline kernel didn't contain any mechanisms making it possible to avoid races between wakeup and system suspend. Generally, there are two problems in that area. First, if a wakeup event occurs exactly when /sys/power/state is being written to, it may be delivered to user space right before the freezer kicks in, so the user space consumer of the event may not be able to process it before the system is suspended. Second, if a wakeup event occurs after user space has been frozen, it is not generally guaranteed that the ongoing transition of the system into a sleep state will be aborted. To address these issues introduce a new global sysfs attribute, /sys/power/wakeup_count, associated with a running counter of wakeup events and three helper functions, pm_stay_awake(), pm_relax(), and pm_wakeup_event(), that may be used by kernel subsystems to control the behavior of this attribute and to request the PM core to abort system transitions into a sleep state already in progress. The /sys/power/wakeup_count file may be read from or written to by user space. Reads will always succeed (unless interrupted by a signal) and return the current value of the wakeup events counter. Writes, however, will only succeed if the written number is equal to the current value of the wakeup events counter. If a write is successful, it will cause the kernel to save the current value of the wakeup events counter and to abort the subsequent system transition into a sleep state if any wakeup events are reported after the write has returned. [The assumption is that before writing to /sys/power/state user space will first read from /sys/power/wakeup_count. Next, user space consumers of wakeup events will have a chance to acknowledge or veto the upcoming system transition to a sleep state. Finally, if the transition is allowed to proceed, /sys/power/wakeup_count will be written to and if that succeeds, /sys/power/state will be written to as well. Still, if any wakeup events are reported to the PM core by kernel subsystems after that point, the transition will be aborted.] Additionally, put a wakeup events counter into struct dev_pm_info and make these per-device wakeup event counters available via sysfs, so that it's possible to check the activity of various wakeup event sources within the kernel. To illustrate how subsystems can use pm_wakeup_event(), make the low-level PCI runtime PM wakeup-handling code use it. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: markgross <markgross@thegnar.org> Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
* Merge branch 'acpica' of ↵Linus Torvalds2010-03-011-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 * 'acpica' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: ACPI: replace acpi_integer by u64 ACPICA: Update version to 20100121. ACPICA: Remove unused uint32_struct type ACPICA: Disassembler: Remove obsolete "Integer64" field in parse object ACPICA: Remove obsolete ACPI_INTEGER (acpi_integer) type ACPICA: Predefined name repair: fix NULL package elements ACPICA: AcpiGetDevices: Eliminate unnecessary _STA calls ACPICA: Update all ACPICA copyrights and signons to 2010 ACPICA: Update for new gcc-4 warning options
| * ACPI: replace acpi_integer by u64Lin Ming2010-01-281-1/+1
| | | | | | | | | | | | | | | | acpi_integer is now obsolete and removed from the ACPICA code base, replaced by u64. Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | PCI / ACPI / PM: Platform support for PCI PME wake-upRafael J. Wysocki2010-02-221-0/+211
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although the majority of PCI devices can generate PMEs that in principle may be used to wake up devices suspended at run time, platform support is generally necessary to convert PMEs into wake-up events that can be delivered to the kernel. If ACPI is used for this purpose, PME signals generated by a PCI device will trigger the ACPI GPE associated with the device to generate an ACPI wake-up event that we can set up a handler for, provided that everything is configured correctly. Unfortunately, the subset of PCI devices that have GPEs associated with them is quite limited. The devices without dedicated GPEs have to rely on the GPEs associated with other devices (in the majority of cases their upstream bridges and, possibly, the root bridge) to generate ACPI wake-up events in response to PME signals from them. Add ACPI platform support for PCI PME wake-up: o Add a framework making is possible to use ACPI system notify handlers for run-time PM. o Add new PCI platform callback ->run_wake() to struct pci_platform_pm_ops allowing us to enable/disable the platform to generate wake-up events for given device. Implemet this callback for the ACPI platform. o Define ACPI wake-up handlers for PCI devices and PCI root buses and make the PCI-ACPI binding code register wake-up notifiers for all PCI devices present in the ACPI tables. o Add function pci_dev_run_wake() which can be used by PCI drivers to check if given device is capable of generating wake-up events at run time. Developed in cooperation with Matthew Garrett <mjg@redhat.com>. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI/PM: Propagate wake-up enable for PCIe devices tooRafael J. Wysocki2009-12-161-8/+2
| | | | | | | | | | | | | | Having read the PM part of the PCIe 2.0 specification more carefully I think that it was a mistake to restrict the wake-up enable propagation to non-PCIe devices, because if we do not request control of the root ports' PME registers via OSC, PCIe PME is supposed to be handled by the platform, just like the non-PCIe PME. Even if we do that, the wake-up propagation is done to allow the devices to wake up the system from sleep states which involves the platform anyway, so it won't hurt. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: use pci_is_pcie() in pci coreKenji Kaneshige2009-11-241-2/+2
| | | | | | | | Change for PCI core to use pci_is_pcie() instead of checking pci_dev->is_pcie. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI / ACPI PM: Propagate wake-up enable for devices w/o ACPI supportRafael J. Wysocki2009-09-091-2/+24
| | | | | | | | | | | | | | | | | | | | | Some PCI devices (not PCI Express), like PCI add-on cards, can generate PME#, but they don't have any special platform wake-up support. For this reason, even if they generate PME# to wake up the system from a sleep state, wake-up events are not generated by the platform. It turns out that, at least on some systems, PCI bridges and the PCI host bridge have ACPI GPEs associated with them that, if enabled to generate wake-up events, allow the system to wake up if one of the add-on devices asserts PME# while the system is in a sleep state. Following this observation, if a PCI device without direct ACPI wake-up support is prepared to wake up the system during a transition into a sleep state (eg. suspend to RAM), try to configure the bridges on the path from the device to the root bridge to wake-up the system. Reviewed-by: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI / ACPI PM: Rework some debug messagesRafael J. Wysocki2009-09-091-11/+2
| | | | | | | | | | Move a debug message from acpi_pci_sleep_wake() to acpi_pm_device_sleep_wake() and use the standard dev_*() macros in there. Reviewed-by: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI PM: Simplify PCI wake-up codeRafael J. Wysocki2009-09-091-3/+7
| | | | | | | | | Rework the PCI wake-up code so that it's easier to read without changing the functionality. Reviewed-by: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* Merge branch 'linus' into releaseLen Brown2009-04-051-215/+0
|\ | | | | | | | | | | | | Conflicts: arch/x86/kernel/cpu/cpufreq/longhaul.c Signed-off-by: Len Brown <len.brown@intel.com>
| * PCI/ACPI: move _OSC code to pci_root.cKenji Kaneshige2009-03-191-215/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move PCI _OSC management code from drivers/pci/pci-acpi.c to drivers/acpi/pci_root.c. The benefits are - We no longer need struct osc_data and its management code (contents are moved to struct acpi_pci_root). This simplify the code, and we no longer care about kmalloc() failure. - We can make pci_acpi_osc_support() be a static function, which is called only from drivers/acpi/pci_root.c. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Reviewed-by: Andrew Patterson <andrew.patterson@hp.com> Tested-by: Andrew Patterson <andrew.patterson@hp.com> Acked-by: Alex Chiang <achiang@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* | ACPICA: Update FADT flag definitionsBob Moore2009-03-261-2/+2
|/ | | | | | | | | Add new flags in the Boot Architecture flags field. Update comments for all FADT flags. Add FADT version when each flag was defined. Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* Merge branch 'linus' into releaseLen Brown2009-01-091-44/+38
|\
| * pci-acpi: Cleanup _OSC evaluation codeTaku Izumi2009-01-071-17/+14
| | | | | | | | | | | | | | | | | | | | | | Cleanup _OSC evaluation code. Some whitespace changes and a few other minor cleanups. Reviewed-by: Andrew Patterson <andrew.patterson@hp.com> Tested-by: Andrew Patterson <andrew.patterson@hp.com> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI/ACPI: Remove unnecessary _OSC evaluation for control requestTaku Izumi2009-01-071-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | If a control had already been granted, we don't need to re-evaluate _OSC for it because firmware may not reject control of any feature it has previously granted control to. Reviewed-by: Andrew Patterson <andrew.patterson@hp.com> Tested-by: Andrew Patterson <andrew.patterson@hp.com> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: revert additional _OSC evaluationTaku Izumi2009-01-071-13/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reverts adf411b819adc9fa96e9b3e638c7480d5e71d270. The commit adf411b819adc9fa96e9b3e638c7480d5e71d270 was based on the improper assumption that queried result was not updated when _OSC support field was changed. But, in fact, queried result is updated whenever _OSC support field was changed through __acpi_query_osc(). As a result, the commit adf411b819adc9fa96e9b3e638c7480d5e71d270 only introduced unnecessary additional _OSC evaluation... Tested-by: Andrew Patterson <andrew.patterson@hp.com> Reviewed-by: Andrew Patterson <andrew.patterson@hp.com> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * ACPI/PCI: remove obsolete _OSC capability support functionsAndrew Patterson2009-01-071-25/+0
| | | | | | | | | | | | | | | | | | | | | | The acpi_query_osc, __pci_osc_support_set, pci_osc_support_set, and pcie_osc_support_set functions have been obsoleted in favor of setting these capabilities during root bridge discovery with pci_acpi_osc_support. There are no longer any callers of these functions, so remove them. Signed-off-by: Andrew Patterson <andrew.patterson@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * ACPI/PCI: call _OSC support during root bridge discoveryAndrew Patterson2009-01-071-5/+19
| | | | | | | | | | | | | | | | | | | | Add pci_acpi_osc_support() and call it when a PCI bridge is added. This allows us to avoid having every individual PCI root bridge driver call _OSC support for every root bridge in their probe functions, a significant savings in boot time. Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: struct device - replace bus_id with dev_name(), dev_set_name()Kay Sievers2009-01-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is part of a larger patch series which will remove the "char bus_id[20]" name string from struct device. The device name is managed in the kobject anyway, and without any size limitation, and just needlessly copied into "struct device". To set and read the device name dev_name(dev) and dev_set_name(dev) must be used. If your code uses static kobjects, which it shouldn't do, "const char *init_name" can be used to statically provide the name the registered device should have. At registration time, the init_name field is cleared, to enforce the use of dev_name(dev) to access the device name at a later time. We need to get rid of all occurrences of bus_id in the entire tree to be able to enable the new interface. Please apply this patch, and possibly convert any remaining remaining occurrences of bus_id. Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-Off-By: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* | ACPI: remove private acpica headers from driver filesLin Ming2008-12-311-2/+0
|/ | | | | | | External driver files should not include any private acpica headers. Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* PCI: ignore bit0 of _OSC return codeKenji Kaneshige2008-11-111-7/+8
| | | | | | | | | | | | | | | | | | | | Currently acpi_run_osc() checks all the bits in _OSC result code (the first DWORD in the capabilities buffer) to see error condition. But the bit 0, which doesn't indicate any error, must be ignored. The bit 0 is used as the query flag at _OSC invocation time. Some platforms clear it during _OSC evaluation, but the others don't. On latter platforms, current acpi_run_osc() mis-detects error when _OSC is evaluated with query flag set because it doesn't ignore the bit 0. Because of this, the __acpi_query_osc() always fails on such platforms. And this is the cause of the problem that pci_osc_control_set() doesn't work since the commit 4e39432f4df544d3dfe4fc90a22d87de64d15815 which changed pci_osc_control_set() to use __acpi_query_osc(). Tested-by:"Tomasz Czernecki <czernecki@gmail.com> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* ACPI: Oops in ACPI with git latestRafael J. Wysocki2008-10-251-0/+3
| | | | | | | | | | | | ACPI Warning (nseval-0168): Insufficient arguments - method [_OSC] needs 5, found 4 [20080926] ACPI Warning (nspredef-0252): \_SB_.PCI0._OSC: Parameter count mismatch - ASL declared 5, expected 4 [20080926] ACPI Error (nspredef-0163): \_SB_.PCI0._OSC: Missing expected return value [20080926] BUG: unable to handle kernel NULL pointer dereference at 00000000 IP: [<c0237671>] acpi_run_osc+0xa1/0x170 Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Tested-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI/PCI: Fix return value of acpi_cuery_osc()Taku Izumi2008-10-221-4/+3
| | | | | | | | | | | | If acpi_query_osc() returns other than AE_OK, __pci_osc_support_set() stops scanning ACPI objects to evaluate _OSC. This prevents subsequent _OSCs from being evaluated if some of root bridge doesn't have _OSC, for example. So acpi_query_osc() should return always AE_OK to evaluate all _OSC. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* ACPI/PCI: Always query _OSC control field in pci_osc_control_set()Taku Izumi2008-10-221-18/+13
| | | | | | | | | | | | | | | In current pci_osc_control_set() implementation, once the _OSC control field is queried, it is never queried again. But the query result can change depending on the _OSC support field. For example, if PCI Express Native Hot Plug control depends on ASPM support on a certain platform, a PCI Express Native Hot Plug Control query would fail before the ASPM driver was loaded, but it would succeed if the ASPM driver was loaded first. Therefore, pci_osc_control_set() should query the _OSC control field every time. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* ACPI/PCI: Change pci_osc_control_set() to query control bits firstTaku Izumi2008-10-221-16/+31
| | | | | | | | | | | | | | Current pci_osc_control_set() evaluates _OSC without query for control bits, unless __pci_osc_support_set() is called beforehand. But as strongly recommended in PCI firmware specification, it should query control bits first. This patch changes pci_osc_control_set() to query control bits first even if __pci_osc_support_set() is not called beforehand. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* ACPI/PCI: Fix possible race condition on _OSC evaluationTaku Izumi2008-10-221-8/+20
| | | | | | | | | | | | Fix possible race condition on _OSC evaluation. Current _OSC evaluation code has possible race condition because it maniputes osc_data linked list or its contents without any lock mechanism. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: disable ASPM per ACPI FADT settingShaohua Li2008-07-281-0/+7
| | | | | | | | | | The ACPI FADT table includes an ASPM control bit. If the bit is set, do not enable ASPM since it may indicate that the platform doesn't actually support the feature. Tested-by: Jack Howarth <howarth@bromo.msbb.uc.edu> Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI ACPI: Rework PCI handling of wake-upRafael J. Wysocki2008-07-071-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Introduce function acpi_pm_device_sleep_wake() for enabling and disabling the system wake-up capability of devices that are power manageable by ACPI. * Introduce function acpi_bus_can_wakeup() allowing other (dependent) subsystems to check if ACPI is able to enable the system wake-up capability of given device. * Introduce callback .sleep_wake() in struct pci_platform_pm_ops and for the ACPI PCI 'driver' make it use acpi_pm_device_sleep_wake(). * Introduce callback .can_wakeup() in struct pci_platform_pm_ops and for the ACPI 'driver' make it use acpi_bus_can_wakeup(). * Move the PME# handlig code out of pci_enable_wake() and split it into two functions, pci_pme_capable() and pci_pme_active(), allowing the caller to check if given device is capable of generating PME# from given power state and to enable/disable the device's PME# functionality, respectively. * Modify pci_enable_wake() to use the new ACPI callbacks and the new PME#-related functions. * Drop the generic .platform_enable_wakeup() callback that is not used any more. * Introduce device_set_wakeup_capable() that will set the power.can_wakeup flag of given device. * Rework PCI device PM initialization so that, if given device is capable of generating wake-up events, either natively through the PME# mechanism, or with the help of the platform, its power.can_wakeup flag is set and its power.should_wakeup flag is unset as appropriate. * Make ACPI set the power.can_wakeup flag for devices found to be wake-up capable by it. * Make the ACPI wake-up code enable/disable GPEs for devices that have the wakeup.flags.prepared flag set (which means that their wake-up power has been enabled). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: rework pci_set_power_state function to call platform firstRafael J. Wysocki2008-07-071-6/+10
| | | | | | | | | | | | | | | | Rework pci_set_power_state() so that the platform callback is invoked before the native mechanism, if necessary. Also, make the function check if the device is power manageable by the platform before invoking the platform callback. This may matter if the device dependent on additional power resources controlled by the platform is being put into D0, in which case those power resources must be turned on before we attempt to handle the device itself. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Introduce platform_pci_power_manageable functionRafael J. Wysocki2008-07-071-6/+13
| | | | | | | | | | | Introduce function pointer platform_pci_power_manageable to be used by the platform-related code to point to a function allowing us to check if given device is power manageable by the platform. Introduce acpi_pci_power_manageable() playing that role for ACPI. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* Merge branch 'suspend' of ↵Jesse Barnes2008-06-121-4/+2
|\ | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 into linux-next
| * PCI ACPI: Drop the second argument of platform_pci_choose_stateRafael J. Wysocki2008-06-111-2/+1
| | | | | | | | | | | | | | | | | | Since the second argument of acpi_pci_choose_state() and platform_pci_choose_state() is never used, remove it. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI PM: acpi_pm_device_sleep_state() cleanupDavid Brownell2008-06-111-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | Get rid of a superfluous acpi_pm_device_sleep_state() parameter. The only legitimate value of that parameter must be derived from the first parameter, which is what all the callers already do. (However, this does not address the fact that ACPI still doesn't set up those flags.) Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
* | pci-acpi: formatting cleanups for _OSCKenji Kaneshige2008-06-101-2/+3
| | | | | | | | | | | | | | | | Minor cleanup in pci-acpi.c. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Acked-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* | pci-acpi: remove unused variable in __pci_osc_support_setKenji Kaneshige2008-06-101-11/+4
| | | | | | | | | | | | | | | | | | The 'retval' variable in __pci_osc_support_set() is no longer used. Remove this unused variable. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Acked-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* | pci-acpi: add flag to indicate query had been doneKenji Kaneshige2008-06-101-1/+3
| | | | | | | | | | | | | | | | | | | | | | Current pci-acpi implementation checks osc_data->support_stat to see if control bits had been already queried. It is not good from the viewpoint of easy understanding. So this patch adds new 'is_queried' flag to indicate query had been done. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Acked-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* | pci-acpi: use local buffer for _OSCKenji Kaneshige2008-06-101-34/+39
| | | | | | | | | | | | | | | | | | | | | | Current pci-acpi implementation uses array in osc_data directly to evaluate _OSC. It needs to save the old data and restore it if _OSC evaluation fails. To make it more robust, we should use local array to evaluate _OSC. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Acked-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* | pci-acpi: remove duplicate code for _OSCKenji Kaneshige2008-06-101-110/+55
|/ | | | | | | | | Remove the duplicated code in acpi_query_osc() and acpi_run_osc(). It simplifies the code very much. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Acked-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* ACPI/PCI: another multiple _OSC memory leak fixKenji Kaneshige2008-05-131-1/+7
| | | | | | | | | | The acpi_query_osc() function can be called for the ACPI object that doesn't have _OSC method. In this case, acpi_get_osc_data() would allocate a useless memory region. To avoid this, we need to check the existence of _OSC before calling acpi_get_osc_data() in acpi_query_osc(). Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* ACPI/PCI: handle multiple _OSCKenji Kaneshige2008-05-131-1/+7
| | | | | | | | | | | The pci_osc_control_set() function can be called for the ACPI object that doesn't have _OSC method. In this case, acpi_get_osc_data() would allocate a useless memory region. To avoid this, we need to check the existence of _OSC before calling acpi_get_osc_data(). Here is a patch to fix this problem in pci_osc_control_set. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* ACPI/PCI: handle multiple _OSCShaohua Li2008-05-131-29/+66
| | | | | | | | | | There is an IA64 system here which have two pci root bridges with _OSC. One _OSC disables SHPC control bit but the other not. Below patch makes _OSC data per-device instead of one global, otherwise linux takes both root bridges don't support SHPC. Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI ACPI: fix uninitialized variable in __pci_osc_support_setKenji Kaneshige2008-05-131-1/+1
| | | | | | | | | | | | | | | Fix uninitialized variable in __pci_osc_support_set(). If the ACPI namespace doesn't have any device object corresponding to the specified hid, 'retval' in __pci_osc_support_set() is not changed by the acpi_query_osc() callback. Since 'retval' is not initizlized in the current implementation, the contents of 'retval' is undefined in this case. This causes a mis-handling of ctrlset_buf[OSC_SUPPORT_TYPE] and will cause an unexpected result in the subsequent pci_osc_control_set() call as a result. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* ACPI: acpi_pci_set_power_state() cleanupsDavid Brownell2008-02-231-8/+16
| | | | | | | | | | Minor cleanups to acpi_pci_set_power_state(): use the ACPI and PCI state symbols to make clear that a mapping is being done between PCI and ACPI states, instead of using magic numbers. For paranoia's sake, report any errors. Save five bytes (x86_64) too. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Len Brown <len.brown@intel.com>
generated by cgit v1.1 at 2024-05-13 15:27:23 +0000