An error occurred fetching the project authors.
- 19 Aug, 2003 2 commits
-
-
Patrick Mochel authored
Instead of putting them in struct device_driver (which few, if any drivers use directly), put them in the controlling bus_type of the device (which are currently responsible for claiming the methods and forwarding the calls to the bus-specific driver anyway). This will save 8 bytes per driver instance, which isn't that much, but it's something. It also makes it more obvious to the reader what is going on. And, it makes for easier bus-level defaults in the case the device has no driver attached. The old calls remain until all instances have been fixed up.
-
Patrick Mochel authored
- From conversations with Ben Herrenschmidt. Most devices should be able to handle powering down with interrupts enabled, which I already assume. But since suspending will stop I/O transactions before the call to power it off (making the device unusable anyway), there is no need to separate the calls - we may as well make it simpler for driver authors and require that driver authors do everything at the same time. There will always be devices that need to either power down or power up the device with interrupts disabled. They will get called with interrupts enabled, but may return -EAGAIN to be called again with interrupts disabled to do what they need to do. System devices are now always called only with interrupts disabled. Come on - they're system devices. Of course we need interrupts disabled.
-
- 12 Aug, 2003 1 commit
-
-
Patrick Mochel authored
dpm_runtime_{suspend,resume} control the power state of a single device while the system is running. dpm_runtime_suspend() will save state of the device, then attempt to power it down. This happens with interrupts enabled, so if the device does not support that, the device's state is restored, and we continue on our merry way. dpm_runtime_resume() powers the device back on, then restores state of the device. dpm_set_power_state() simply notifies the core of the power state the device is in. Drivers can use this, since they are the only ones that can really tell.
-
- 08 Aug, 2003 1 commit
-
-
Patrick Mochel authored
We don't need the spinlock to protect the lists (at least not now), since we have a semaphore to synchronize all operations device PM operations.
-
- 07 Aug, 2003 1 commit
-
-
Patrick Mochel authored
- Split calls into - device_pm_suspend() [ Saving device state. ] - device_pm_power_down() [ Powering devices down. ] - device_pm_power_up() [ Powering devices up. ] - device_pm_resume() [ Restoring device state. ] - Walk local dpm_active list when suspending devices, and move devices to dpm_suspended list when ->suspend() is called. - Walk dpm_suspended list to power down devices (with interrrupts enabled.) - Try to power down devices with IRQs on. - If they succeed, move them to dpm_off list. - If they return -EAGAIN, move them to dpm_off_irq list. - Disable interrupts and suspend devices needed interrupts off. - Do converse on resume - power on devices that need interrupts off and move them to dpm_suspended. - Enable interrupts. - Power on all other devices and move them to dpm_suspended. - Restore state of all devices and move them to dpm_active.
-
- 06 Aug, 2003 1 commit
-
-
Patrick Mochel authored
- Create drivers/base/power/ - Move drivers/base/power.c there. - Split into shutdown.c suspend.c and resume.c
-