Messages in this thread | | | Subject | Re: PCI power management | Date | Thu, 19 Apr 2001 13:57:57 +0100 (BST) | From | Alan Cox <> |
| |
> - Some devices just can't be brought back to life from D3 state without > a PCI reset (ATI Rage M3 for example) and that require some arch specific > support (when it's possible at all).
Putting on a driver author hat what I want is
pci_power_on_generic pci_power_off_generic pci_power_on_null pci_power_off_null
At which point most driver writers are having to do no thinking at all about their device. The PCI layer just requires they pick a function and stick it in the struct pci_device.
> - On SMP, we need some way to stop other CPUs in the scheduler > while running the last round of sleep (putting devices to sleep) at least > until all IO layers in Linux can properly handle blocking of IO queues > while the device sleeps.
This doesnt help you. You need device specific support in each case where bus mastering is occuring and a bus master error could be fatal if missed. For example on i2o I can easily have 4Mbytes of outstanding I/O between the message layer and disk, all of which is bus mastering. Only the driver actually knows when its idle.
> that bang hardware directly (X, but not only X) need to be properly > suspended (and the kernel has to wait for ack from them before continuing > with devices sleep).
X has hooks for this in XFree 4
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |