> - 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/
This archive was generated by hypermail 2b29 : Mon Apr 23 2001 - 21:00:31 EST