07 Jan, 2012
1 commit
-
Include the driver name and device in warning when a pci driver
supports both legacy pm and new framework as just the stack trace
gives no way to identify the driver.Signed-off-by: David Fries
Acked-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes
06 Jul, 2011
1 commit
-
A subsequent patch is going to move the invocation of
pm_runtime_barrier() from dpm_prepare() to __device_suspend().
Consequently, early wakeup events resulting from runtime resume
requests for wakeup devices queued up right before system suspend
will only be detected after all of the subsystem-level .prepare()
callbacks have run. However, the PCI bus type calls
pm_runtime_get_sync() from its pci_pm_prepare() callback routine,
so it would destroy the early wakeup events information regarding PCI
devices. To prevent this from happening add an early wakeup
detection mechanism, analogous to the one currently in dpm_prepare(),
to pci_pm_prepare().Signed-off-by: Rafael J. Wysocki
Acked-by: Jesse Barnes
22 Jun, 2011
1 commit
-
After commit e8665002477f0278f84f898145b1f141ba26ee26
(PM: Allow pm_runtime_suspend() to succeed during system suspend) it
is possible that a device resumed by the pm_runtime_resume(dev) in
pci_pm_prepare() will be suspended immediately from a work item,
timer function or otherwise, defeating the very purpose of calling
pm_runtime_resume(dev) from there. To prevent that from happening
it is necessary to increment the runtime PM usage counter of the
device by replacing pm_runtime_resume() with pm_runtime_get_sync().
Moreover, the incremented runtime PM usage counter has to be
decremented by the corresponding pci_pm_complete(), via
pm_runtime_put_sync().Signed-off-by: Rafael J. Wysocki
Cc: stable@kernel.org
Acked-by: Jesse Barnes
12 Apr, 2011
1 commit
-
Xen save/restore is going to use hibernate device callbacks for
quiescing devices and putting them back to normal operations and it
would need to select CONFIG_HIBERNATION for this purpose. However,
that also would cause the hibernate interfaces for user space to be
enabled, which might confuse user space, because the Xen kernels
don't support hibernation. Moreover, it would be wasteful, as it
would make the Xen kernels include a substantial amount of code that
they would never use.To address this issue introduce new power management Kconfig option
CONFIG_HIBERNATE_CALLBACKS, such that it will only select the code
that is necessary for the hibernate device callbacks to work and make
CONFIG_HIBERNATION select it. Then, Xen save/restore will be able to
select CONFIG_HIBERNATE_CALLBACKS without dragging the entire
hibernate code along with it.Signed-off-by: Rafael J. Wysocki
Tested-by: Shriram Rajagopalan
15 Mar, 2011
1 commit
-
After redefining CONFIG_PM to depend on (CONFIG_PM_SLEEP ||
CONFIG_PM_RUNTIME) the CONFIG_PM_OPS option is redundant and can be
replaced with CONFIG_PM.Signed-off-by: Rafael J. Wysocki
24 Dec, 2010
2 commits
-
Fix kernel-doc warning for __pci_device_probe():
Warning(drivers/pci/pci-driver.c:341): missing initial short description on line:
* __pci_device_probe()Signed-off-by: Randy Dunlap
Signed-off-by: Jesse Barnes -
pci_restore_state only ever returns 0, thus there is no benefit in
having it return any value. Also, a large majority of the callers do
not check the return code of pci_restore_state. Make the
pci_restore_state a void return and avoid the overhead.Acked-by: Mauro Carvalho Chehab
Signed-off-by: Jon Mason
Signed-off-by: Jesse Barnes
31 Jul, 2010
1 commit
-
This patch (as1388) changes the way the PCI core handles runtime PM
settings when probing or unbinding drivers. Now the core will make
sure the device is enabled for runtime PM, with a usage count >= 1,
when a driver is probed. It does the same when calling a driver's
remove method.If the driver wants to use runtime PM, all it has to do is call
pm_runtime_pu_noidle() near the end of its probe routine (to cancel
the core's usage increment) and pm_runtime_get_noresume() near the
start of its remove routine (to restore the usage count). It does not
need to mess around with setting the runtime state to enabled,
disabled, active, or suspended.The patch updates e1000e and r8169, the only PCI drivers that already
use the existing runtime PM interface.Signed-off-by: Alan Stern
Acked-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes
23 Feb, 2010
1 commit
-
Introduce run-time PM callbacks for the PCI bus type. Make the new
callbacks work in analogy with the existing system sleep PM
callbacks, so that the drivers already converted to struct dev_pm_ops
can use their suspend and resume routines for run-time PM without
modifications.Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes
16 Sep, 2009
1 commit
-
* 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: (75 commits)
PCI hotplug: clean up acpi_run_hpp()
PCI hotplug: acpiphp: use generic pci_configure_slot()
PCI hotplug: shpchp: use generic pci_configure_slot()
PCI hotplug: pciehp: use generic pci_configure_slot()
PCI hotplug: add pci_configure_slot()
PCI hotplug: clean up acpi_get_hp_params_from_firmware() interface
PCI hotplug: acpiphp: don't cache hotplug_params in acpiphp_bridge
PCI hotplug: acpiphp: remove superfluous _HPP/_HPX evaluation
PCI: Clear saved_state after the state has been restored
PCI PM: Return error codes from pci_pm_resume()
PCI: use dev_printk in quirk messages
PCI / PCIe portdrv: Fix pcie_portdrv_slot_reset()
PCI Hotplug: convert acpi_pci_detect_ejectable() to take an acpi_handle
PCI Hotplug: acpiphp: find bridges the easy way
PCI: pcie portdrv: remove unused variable
PCI / ACPI PM: Propagate wake-up enable for devices w/o ACPI support
ACPI PM: Replace wakeup.prepared with reference counter
PCI PM: Introduce device flag wakeup_prepared
PCI / ACPI PM: Rework some debug messages
PCI PM: Simplify PCI wake-up code
...Fixed up conflict in arch/powerpc/kernel/pci_64.c due to OF device tree
scanning having been moved and merged for the 32- and 64-bit cases. The
'needs_freset' initialization added in 6e19314cc ("PCI/powerpc: support
PCIe fundamental reset") is now in arch/powerpc/kernel/pci_of_scan.c.
15 Sep, 2009
2 commits
-
Some PCI devices fail if their standard configuration registers are
restored twice in a row. Prevent this from happening by making
pci_restore_state() clear the saved_state flag of the device right
after the device's standard configuration registers have been
populated with the previously saved values.Simplify PCI PM callbacks by removing the direct clearing of
state_saved from them, as it shouldn't be necessary any more (except
in pci_pm_thaw(), where it has to be cleared, so that the values saved
during the "freeze" phase of hibernation are not used later by mistake).Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes -
Currently pci_pm_resume() always returns 0, which makes the error
variable defined in there a bit pointless. Make pci_pm_resume()
return error codes obtained from drivers' callbacks.Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes
10 Sep, 2009
1 commit
-
Separate out pci_add_dynid() from store_new_id() and export it so that
in-kernel code can add PCI IDs dynamically. As the function will be
available regardless of HOTPLUG, put it and pull pci_free_dynids()
outside of CONFIG_HOTPLUG.This will be used by pci-stub to initialize initial IDs via module
param.While at it, remove bogus get_driver() failure check.
Signed-off-by: Tejun Heo
Acked-by: Greg Kroah-Hartman
Reviewed-by: Grant Grundler
Signed-off-by: Jesse Barnes
28 Aug, 2009
1 commit
21 Aug, 2009
1 commit
-
Without the check, the config space may be filled with zeros. Though
the driver should try to avoid call restoring before saving, but the
pci layer also should check this.Also removes the existing check in pci_restore_standard_config, since
it's superfluous with the new check in restore_state.Acked-by: Rafael J. Wysocki
Signed-off-by: Alek Du
Signed-off-by: Jesse Barnes
25 Jul, 2009
1 commit
-
They are not supposed to be modified by drivers, so make them const.
Signed-off-by: Dmitry Torokhov
Acked-by: Greg Kroah-Hartman
Signed-off-by: Rafael J. Wysocki
06 Apr, 2009
1 commit
-
* git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-cpumask: (36 commits)
cpumask: remove cpumask allocation from idle_balance, fix
numa, cpumask: move numa_node_id default implementation to topology.h, fix
cpumask: remove cpumask allocation from idle_balance
x86: cpumask: x86 mmio-mod.c use cpumask_var_t for downed_cpus
x86: cpumask: update 32-bit APM not to mug current->cpus_allowed
x86: microcode: cleanup
x86: cpumask: use work_on_cpu in arch/x86/kernel/microcode_core.c
cpumask: fix CONFIG_CPUMASK_OFFSTACK=y cpu hotunplug crash
numa, cpumask: move numa_node_id default implementation to topology.h
cpumask: convert node_to_cpumask_map[] to cpumask_var_t
cpumask: remove x86 cpumask_t uses.
cpumask: use cpumask_var_t in uv_flush_tlb_others.
cpumask: remove cpumask_t assignment from vector_allocation_domain()
cpumask: make Xen use the new operators.
cpumask: clean up summit's send_IPI functions
cpumask: use new cpumask functions throughout x86
x86: unify cpu_callin_mask/cpu_callout_mask/cpu_initialized_mask/cpu_sibling_setup_mask
cpumask: convert struct cpuinfo_x86's llc_shared_map to cpumask_var_t
cpumask: convert node_to_cpumask_map[] to cpumask_var_t
x86: unify 32 and 64-bit node_to_cpumask_map
...
02 Apr, 2009
1 commit
-
* 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: (88 commits)
PCI: fix HT MSI mapping fix
PCI: don't enable too much HT MSI mapping
x86/PCI: make pci=lastbus=255 work when acpi is on
PCI: save and restore PCIe 2.0 registers
PCI: update fakephp for bus_id removal
PCI: fix kernel oops on bridge removal
PCI: fix conflict between SR-IOV and config space sizing
powerpc/PCI: include pci.h in powerpc MSI implementation
PCI Hotplug: schedule fakephp for feature removal
PCI Hotplug: rename legacy_fakephp to fakephp
PCI Hotplug: restore fakephp interface with complete reimplementation
PCI: Introduce /sys/bus/pci/devices/.../rescan
PCI: Introduce /sys/bus/pci/devices/.../remove
PCI: Introduce /sys/bus/pci/rescan
PCI: Introduce pci_rescan_bus()
PCI: do not enable bridges more than once
PCI: do not initialize bridges more than once
PCI: always scan child buses
PCI: pci_scan_slot() returns newly found devices
PCI: don't scan existing devices
...Fix trivial append-only conflict in Documentation/feature-removal-schedule.txt
31 Mar, 2009
5 commits
-
Conflicts:
arch/x86/include/asm/topology.h
drivers/oprofile/buffer_sync.c
(Both cases: changed in Linus' tree, removed in Ingo's). -
At present the configuration spaces of PCI devices that have no
drivers or no PM support in the drivers (either legacy or through a
pm object) are not saved during suspend and, consequently, they are
not restored during resume. This generally may lead to the state of
the system being slightly inconsistent after the resume, so it's
better to save and restore the configuration spaces of these devices
as well.Signed-off-by: Rafael J. Wysocki
Acked-by: Ingo Molnar
Acked-by: Jesse Barnes -
Once we have allowed timer interrupts to be enabled during the late
phase of suspending devices, we are now able to use the generic
pci_set_power_state() to put PCI devices into low power states at
that time. We can also use some related platform callbacks, like the
ones preparing devices for wake-up, during the late suspend.Doing this will allow us to avoid the race condition where a device
using shared interrupts is put into a low power state with interrupts
enabled and then an interrupt (for another device) comes in and
confuses its driver. At the same time, devices that don't support
the native PCI PM or that require some additional, platform-specific
operations to be carried out to put them into low power states will
be handled as appropriate.Signed-off-by: Rafael J. Wysocki
Acked-by: Ingo Molnar
Acked-by: Jesse Barnes -
Move pci_restore_standard_config() from pci.c to pci-driver.c and
make it static.Signed-off-by: Rafael J. Wysocki
Acked-by: Ingo Molnar
Acked-by: Jesse Barnes -
I noticed two functions use a variable "i" to store the return value of PM
function calls while the rest of the file uses "error". As "i" normally
indicates a counter of some sort it seems better to keep this consistent.Signed-off-by: Frans Pop
Signed-off-by: Jesse Barnes
Signed-off-by: Rafael J. Wysocki
21 Mar, 2009
2 commits
-
This interface allows the user to force a rescan of all PCI buses
in system, and rediscover devices that have been removed earlier.pci_bus_attrs implementation from Trent Piepho.
Thanks to Vegard Nossum for discovering locking issues with the
sysfs interface.Cc: Trent Piepho
Signed-off-by: Alex Chiang
Signed-off-by: Jesse Barnes -
This adds a remove_id sysfs entry to allow users of new_id to later
remove the added dynid. One use case is management tools that want to
dynamically bind/unbind devices to pci-stub driver while devices are
assigned to KVM guests. Rather than having to track which driver was
originally bound to the driver, a mangement tool can simply:Guest uses device
Signed-off-by: Chris Wright
Signed-off-by: Jesse Barnes
13 Mar, 2009
1 commit
-
Impact: cleanup
node_to_cpumask (and the blecherous node_to_cpumask_ptr which
contained a declaration) are replaced now everyone implements
cpumask_of_node.Signed-off-by: Rusty Russell
05 Feb, 2009
4 commits
-
Currently, the PM core always attempts to manage devices with drivers
that use the new PM framework. In particular, it attempts to disable
the devices (which is unnecessary), to save their state (which may be
undesirable if the driver has done that already) and to put them into
low power states (again, this may be undesirable if the driver has
already put the device into a low power state). That need not be
the right thing to do, so make the core be more careful in this
respect.Generally, there are the following categories of devices to consider:
* bridge devices without drivers
* non-bridge devices without drivers
* bridge devices with drivers
* non-bridge devices with drivers
and each of them should be handled differently.For bridge devices without drivers the PCI PM core will save their
state on suspend and restore it (early) during resume, after putting
them into D0 if necessary. It will not attempt to do anything else
to these devices.For non-bridge devices without drivers the PCI PM core will disable
them and save their state on suspend. During resume, it will put
them into D0, if necessary, restore their state (early) and reenable
them.For bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already.
Still, the core will restore their state (early) during resume,
after putting them into D0, if necessary.For non-bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already. Also,
if the state of the device hasn't been saved by the driver, the core
will attempt to put the device into a low power state. During
resume the core will restore the state of the device (early), after
putting it into D0, if necessary.Signed-off-by: Rafael J. Wysocki
Acked-by: Linus Torvalds
Signed-off-by: Jesse Barnes -
It is a mistake to disable and enable PCI bridges and PCI Express
ports during suspend-resume, at least at the time when it is
currently done. Disabling them may lead to problems with accessing
devices behind them and they should be automatically enabled when
their standard config spaces are restored. Fix this by not attempting
to disable bridges during suspend and enable them during resume.Signed-off-by: Rafael J. Wysocki
Acked-by: Linus Torvalds
Signed-off-by: Jesse Barnes -
Make pci_legacy_suspend() save the state of the device if it is
in PCI_UNKNOWN after its suspend callback has run and warn only if
the power state of the device has been changed by its suspend
callback.Also, use WARN_ONCE(), which is more useful, in pci_legacy_suspend(),
so that the name of the offending function is printed.Additionally, remove the unnecessary line of code setting
pci_dev->state_saved.Signed-off-by: Rafael J. Wysocki
Reported-by: Benjamin Herrenschmidt
Acked-by: Linus Torvalds
Signed-off-by: Jesse Barnes -
Suspend to RAM is reported to break on some machines as a result of
attempting to put one of driverless PCI devices into a low power
state. Avoid that by not attepmting to power manage driverless
devices during suspend.Fix up pci_pm_poweroff() after a previous incomplete fix for the same
thing during hibernation.This patch is reported to fix the regression from 2.6.28 tracked as
http://bugzilla.kernel.org/show_bug.cgi?id=12605Signed-off-by: Rafael J. Wysocki
Reported-and-tested-by: Eric Sesterhenn
Acked-by: Linus Torvalds
Signed-off-by: Jesse Barnes
28 Jan, 2009
2 commits
-
Hibernation breaks on EeePC 701 as a result of attempting to put one
of its (driverless) devices into a low power state. Avoid that by
not attepmting to power manage driverless devices during hibernation.Signed-off-by: Rafael J. Wysocki
Reported-and-tested-by: Alan Jenkins
Signed-off-by: Jesse Barnes -
If one of device drivers refuses to suspend by returning error code
from its ->suspend() callback, the devices that have already been
suspended are resumed by executing their drivers' ->resume()
callbacks. Some of these callbacks expect the device's
configuration space to be restored if the device has been put into
D3 before they are called. Unfortunately, this mechanism has been
broken by recent changes moving the restoration of config spaces
of some devices (most importantly, USB controllers and HDA Intel)
into the resume callbacks executed with interrupts off. Obviously,
these callbacks are not invoked in the suspend error path and, as a
result, the system cannot be successfully brought back into the
working state in case of a suspend error. The same thing happens
in the hibernation error path right before putting the system into
S4.Similarly, the suspend testing facility associated with the
/sys/power/pm_test file is broken, because it uses the very same
mechanism that is used in the suspend and hibernation error paths.Fix the breakage by making the PCI core restore the configuration
spaces of PCI devices that haven't been restored already before
pci_pm_resume() is called for those devices by the PM core.Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes
17 Jan, 2009
1 commit
-
There is a problem in our handling of suspend-resume of PCI devices that
many of them have their standard config registers restored with
interrupts enabled and they are put into the full power state with
interrupts enabled as well. This may lead to the following scenario:
* an interrupt vector is shared between two or more devices
* one device is resumed earlier and generates an interrupt
* the interrupt handler of another device tries to handle it and
attempts to access the device the config space of which hasn't been
restored yet and/or which still is in a low power state
* the system crashes as a resultTo prevent this from happening we should restore the standard
configuration registers of all devices with interrupts disabled and we
should put them into the D0 power state right after that.
Unfortunately, this cannot be done using the existing
pci_set_power_state(), because it can sleep. Also, to do it we have to
make sure that the config spaces of all devices were actually saved
during suspend.Signed-off-by: Rafael J. Wysocki
Acked-by: Linus Torvalds
Signed-off-by: Jesse Barnes
08 Jan, 2009
7 commits
-
Put PM callbacks in drivers/pci/pci-driver.c in the order in which
they are executed which makes it much easier to follow the code.No functional changes should result from this.
Signed-off-by: Rafael J. Wysocki
Acked-by: Pavel Machek
Signed-off-by: Jesse Barnes -
It should be quite clear that it generally makes sense to execute
the default PM callbacks (ie. the callbacks used for handling
suspend, hibernation and resume of PCI devices without drivers) for
all devices. Of course, the drivers that provide legacy PCI PM
support (ie. the ->suspend, ->suspend_late, ->resume_early
or ->resume hooks in the pci_driver structure), carry out these
operations too, so we can't do it for devices with such drivers.
Still, we can make the default PM callbacks run for devices with
drivers using the new framework (ie. implement the pm object), since
there are no such drivers at the moment.This also simplifies the code and makes it smaller.
Signed-off-by: Rafael J. Wysocki
Acked-by: Pavel Machek
Signed-off-by: Jesse Barnes -
The size of drivers/pci/pci-driver.c can be reduced quite a bit
if pci_fixup_device() is called from the legacy PM callbacks, so make
it happen.No functional changes should result from this.
Signed-off-by: Rafael J. Wysocki
Acked-by: Pavel Machek
Signed-off-by: Jesse Barnes -
Rename two functions and rearrange code in drivers/pci/pci-driver.c
so that it's easier to follow. In particular, separate invocations
of the legacy callbacks from the rest of the new callbacks' code.Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes -
It generally is better to avoid accessing devices behind bridges that
may not be in the D0 power state, because in that case the bridges'
secondary buses may not be accessible. For this reason, during the
early phase of resume (ie. with interrupts disabled), before
restoring the standard config registers of a device, check the power
state of the bridge the device is behind and postpone the restoration
of the device's config space, as well as any other operations that
would involve accessing the device, if that state is not D0.In such cases the restoration of the device's config space will be
retried during the "normal" phase of resume (ie. with interrupts
enabled), so that the bridge can be put into D0 before that happens.Also, save standard configuration registers of PCI devices during the
"normal" phase of suspend (ie. with interrupts enabled), so that the
bridges the devices are behind can be put into low power states (we
don't put bridges into low power states at the moment, but we may
want to do it in the future and it seems reasonable to design for
that).Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes -
Move pci_has_legacy_pm_support() closer to the functions that
call it.Signed-off-by: Rafael J. Wysocki
Acked-by: Pavel Machek
Signed-off-by: Jesse Barnes -
PCI devices without drivers can be put into low power states during
suspend with the help of pci_prepare_to_sleep() and prevented from
generating wake-up events during resume with the help of
pci_enable_wake(). However, it's better not to put bridges into
low power states during suspend, because that might result in entire
bus segments being powered off.Signed-off-by: Rafael J. Wysocki
Acked-by: Pavel Machek
Signed-off-by: Jesse Barnes