Robert Hancock wrote to lkml on 2006-05-22:
(full quote for linux1394-devel)
I've been experimenting to track down the cause of suspend/resume
problems on my Compaq Presario X1050 laptop:
http://bugzilla.kernel.org/show_bug.cgi?id=6075
Essentially the ACPI Embedded Controller and keyboard controller would
get into a bizarre, confused state after resume.
I found that unloading the ohci1394 module before suspend and reloading
it after resume made the problem go away. Diffing the dmesg output from
resume, with and without the module loaded, I found that with the module
loaded I was missing these:
PM: Writing back config space on device 0000:02:00.0 at offset 1. (Was 2100080, writing 2100007)
PM: Writing back config space on device 0000:02:00.0 at offset 3. (Was 0, writing 8008)
PM: Writing back config space on device 0000:02:00.0 at offset 4. (Was 0, writing 90200000)
PM: Writing back config space on device 0000:02:00.0 at offset 5. (Was 1, writing 2401)
PM: Writing back config space on device 0000:02:00.0 at offset f. (Was 20000100, writing 2000010a)
The default PCI driver performs the pci_restore_state when no driver is
loaded for the device. When the ohci1394 driver is loaded, it is
supposed to do this, however it appears not to do so.
I created the patch below and tested it, and it appears to resolve the
suspend problems I was having with the module loaded. I only added in
the pci_save_state and pci_restore_state - however, though I know little
of this hardware, surely the driver should really be doing more than
this when suspending and resuming? Currently it does almost nothing,
what if there are commands in progress, etc? As such this is just an RFC.
Thanks, this is at least a start. Apart from the code for PPC
Macintoshs, ohci1394 does indeed lack any suspend/resume handling. I
don't know anything about this matter, however the OHCI spec (gratis
available, linked from www.linux1394.org) table A-11 on page 168 says
which losses of configuration result from what power state transitions:
Interrupts are masked when going into D1. IEEE 1394 configuration is
lost when going into D2. PCI configuration is lost when going into D3.
Since we don't handle this yet, a suspend/resume cycle results at least
in loss of FireWire connectivity.
As you may have guessed, this problem is basically as old as the driver.
Nobody is actively working on it AFAIK. (Except that I dusted off an old
notebook and put a fresh Linux distro on it --- with the plan check
power management and hot ejection handling by ohci1394... later this
year...)
Don't ask me why the failure to save/restore the state of the 1394
controller messes with the keyboard/EC controller, but it apparently does..
Signed-off-by: Robert Hancock <[email protected]>
(Patch attached to stop Thunderbird from destroying it..)
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
--- linux-2.6.16-1.2208_FC6/drivers/ieee1394/ohci1394.c 2006-05-22 12:34:30.000000000 -0600
+++ linux-2.6.16-1.2208_FC6ide/drivers/ieee1394/ohci1394.c 2006-05-22 14:56:53.000000000 -0600
@@ -3539,6 +3539,7 @@ static int ohci1394_pci_resume (struct p
}
#endif /* CONFIG_PPC_PMAC */
+ pci_restore_state(pdev);
pci_enable_device(pdev);
return 0;
@@ -3558,6 +3559,8 @@ static int ohci1394_pci_suspend (struct
}
#endif
+ pci_save_state(pdev);
+
return 0;
}
--
Stefan Richter
-=====-=-==- -=-= ====-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
