Am Freitag, 28. Mai 2004 16:42 schrieben Sie:
> If you have, then where's your patch? :)
attached ;) (I hope this is correctly inlined now. If not I think I have to
patch kmail first...)
> What kernel?
2.6.7-rc1-mm1
> > I think you'd need to include a
> > pci_save_state, pci_disable_device, pci_set_power_state
> > before suspending and
> > pci_set_state, pci_enable_device, (pci_set_power_state?)
> > while resuming.
>
> Odd, that's what I see drivers/usb/core/hcd-pci.c doing right now.
[Urgs] I didn't look there....
However I just debugged a bit more:
My uhci's do not support PM at all, so i disabled the uhci driver.
(The ehci does, however I don't know how windows handles suspend then...).
When I want acpi to go to S3 (echo 3 > /proc/acpi/sleep), the driver want's to
enter S2, which the device does not support:
Stopping tasks:
===================================================================|
radeonfb: suspending to state: 2...
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 0x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 0x mode
ehci_hcd 0000:00:1d.7: suspend D0 --> D2
ehci_hcd 0000:00:1d.7: PCI suspend fail, -5
ehci_hcd 0000:00:1d.7: resume from state D0
This seems to be an acpi problem. I'm no acpi god, and no idea how it works. I
found that every call before acpi has state 3, every afterwards has state 2.
However, even when the driver is put to S3, it is not resumed afterwards, as
it fiddles around with dev->power.power_state.
drivers/base/power/resume.c:dpm_resume doe not resume it, then.
Additionally I suppose, there is a pci_enable_device missing in the resume
code (See patch below).
I removed the power_state code, and added pci_enable_device. The driver
survives a resume now, but the handshakes fail afterwards (even after reload
the module). Dunno why ;( ?
At Least suspend-to-disk (pmdisk) works.
--
Encrypted Mails welcome.
PGP-Key at http://zodiac.dnsalias.org/misc/pgpkey.asc | Key-ID: 0x6D7DD291