Re: [PATCH] make my life easier ...
On Wed, 1 Nov 2000, Martin Mares wrote: > Hello! > > > Aside from all of the other comments that've been made, because the user might > > have tweeked them at boot. ie turn on UDMA. If we just re-initalized on > > wakeup, you loose this. > > I've of course meant reinitialize with the user-supplied settings, just as we > do during normal initialization/configuration of the driver. No, we put it back in the mode it was in before APM wacked. Yes, if we call the settings before APM wacks it 'user settings'. Cheers, Andre Hedrick CTO Timpanogas Research Group EVP Linux Development, TRG Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
On Wed, 1 Nov 2000, Martin Mares wrote: Hello! Aside from all of the other comments that've been made, because the user might have tweeked them at boot. ie turn on UDMA. If we just re-initalized on wakeup, you loose this. I've of course meant reinitialize with the user-supplied settings, just as we do during normal initialization/configuration of the driver. No, we put it back in the mode it was in before APM wacked. Yes, if we call the settings before APM wacks it 'user settings'. Cheers, Andre Hedrick CTO Timpanogas Research Group EVP Linux Development, TRG Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
> certainly accept it), then why not just do the equivalent of a reset in > the high-level IDE driver on coming back from sleep? Possibly together > with forcing any other setup state we know about. Because windows seems to drop the controller back to PIO mode 0 and the BIOS knows about it. At least in the palmax case, although since 2.4test doesnt boot on it as of pre9 I've not tried the 2.4 patches yet. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
Andre Hedrick writes: > APM signals ATA/IDE to goto sleep. > IDE then records and buffers the setup of the host and device. > IDE forces device and host to PIO 0 (imortant step, explain later) > IDE issues spindown and sleep task-command. > IDE returns to APM with success/failure. Insert here... BIOS tries to hibernate to disk and finds the disk already asleep. > success, sets request_queue blocker flag (very critical) _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
LT, I can do it from user-space completely, but not today. The tools are missing. Also I have/will get my traces on my code in a day or so. Cheers, Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
On Thu, 26 Oct 2000, Stephen Rothwell wrote: > > OK, I include below a more or less translation for 2.4. I have not even > compiled this, and have not got the hardware to test it anyway. I disagree violently with doing this in the low-level drivers. If it cannot be done in user space (which is dubious in itself, but I'll certainly accept it), then why not just do the equivalent of a reset in the high-level IDE driver on coming back from sleep? Possibly together with forcing any other setup state we know about. That, together with using the pci_register_driver() thing, would be my preferred approach by far. This kind of low-level twiddling and special casing _will_ come back to haunt us later. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
"H. Peter Anvin" <[EMAIL PROTECTED]> writes: > Followup to: <[EMAIL PROTECTED]> > By author:Martin Mares <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > This doesn't make much sense to me: Why don't we just reinitialize the timings > > as we do when programming the chipset instead of saving/restoring the state? > > > > Also, are you sure BIOSes don't save the IDE controller state when suspending? I my experience, BIOSes do not do anything that you might expect them to :-) (and usually do things you don't want them to ...) > Wrong question. The proper question is "are we not sure the BIOS > doesn't save..." and the answer is "with all the buggy BIOSes out > there, of course not." > > Seriously. Relying on the BIOS any more than the absolutely necessary > minimum is way dangerous. Also, we need to plan for ACPI where we have to do all the power management ourselves ... Cheers, Stephen -- Stephen Rothwell, Open Source Researcher, Linuxcare, Inc. +61-2-62628990 tel, +61-2-62628991 fax [EMAIL PROTECTED], http://www.linuxcare.com/ Linuxcare. Support for the revolution. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
"H. Peter Anvin" [EMAIL PROTECTED] writes: Followup to: [EMAIL PROTECTED] By author:Martin Mares [EMAIL PROTECTED] In newsgroup: linux.dev.kernel This doesn't make much sense to me: Why don't we just reinitialize the timings as we do when programming the chipset instead of saving/restoring the state? Also, are you sure BIOSes don't save the IDE controller state when suspending? I my experience, BIOSes do not do anything that you might expect them to :-) (and usually do things you don't want them to ...) Wrong question. The proper question is "are we not sure the BIOS doesn't save..." and the answer is "with all the buggy BIOSes out there, of course not." Seriously. Relying on the BIOS any more than the absolutely necessary minimum is way dangerous. Also, we need to plan for ACPI where we have to do all the power management ourselves ... Cheers, Stephen -- Stephen Rothwell, Open Source Researcher, Linuxcare, Inc. +61-2-62628990 tel, +61-2-62628991 fax [EMAIL PROTECTED], http://www.linuxcare.com/ Linuxcare. Support for the revolution. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
On Thu, 26 Oct 2000, Stephen Rothwell wrote: OK, I include below a more or less translation for 2.4. I have not even compiled this, and have not got the hardware to test it anyway. I disagree violently with doing this in the low-level drivers. If it cannot be done in user space (which is dubious in itself, but I'll certainly accept it), then why not just do the equivalent of a reset in the high-level IDE driver on coming back from sleep? Possibly together with forcing any other setup state we know about. That, together with using the pci_register_driver() thing, would be my preferred approach by far. This kind of low-level twiddling and special casing _will_ come back to haunt us later. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
LT, I can do it from user-space completely, but not today. The tools are missing. Also I have/will get my traces on my code in a day or so. Cheers, Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
Andre Hedrick writes: APM signals ATA/IDE to goto sleep. IDE then records and buffers the setup of the host and device. IDE forces device and host to PIO 0 (imortant step, explain later) IDE issues spindown and sleep task-command. IDE returns to APM with success/failure. Insert here... BIOS tries to hibernate to disk and finds the disk already asleep. success, sets request_queue blocker flag (very critical) _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
certainly accept it), then why not just do the equivalent of a reset in the high-level IDE driver on coming back from sleep? Possibly together with forcing any other setup state we know about. Because windows seems to drop the controller back to PIO mode 0 and the BIOS knows about it. At least in the palmax case, although since 2.4test doesnt boot on it as of pre9 I've not tried the 2.4 patches yet. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
On Thu, 26 Oct 2000, Stephen Rothwell wrote: > However, on the bus this morning, I though about this again and wondered > that this may not the correct way to do this. What we actually want to > power manage is the PCI device as a whole not each interface independantly, > which I would assume is impossible anyway. Wrong level at this point, IMHO. > 2.4 provides another power management interface for PCI drivers - the > suspend and resume elements of the pci_driver struct. These have > the advantage of the driver being called in the correct order with > respect to power being removed/resumed to the bus that the device > is actually hanging off. Unfortunately, the IDE code does not use > the "new" (quoted from Documentation/pci.txt) pci_register_driver > interface. > > Also, the suspend/resume logic should include code to actually turn > the device off and on. If you do this we may end up deregistering the device and unless APM can remember everything the devices/drives may be lost. > Where do we go from here? First we thank Mark Lord for putting to 'C' what I was banging on for a while. I thinkered with this with a hotswap ATA-model and have the bases, but I do not want to fill either driver with boat loads of code that will be deleted in 2.5 when I rewrite mine. One of the issues to include is bay-swapping that is critical for the testing. This then falls back upon the bases of hotswap device and not just disks. Here is the event path that I think will work. APM signals ATA/IDE to goto sleep. IDE then records and buffers the setup of the host and device. IDE forces device and host to PIO 0 (imortant step, explain later) IDE issues spindown and sleep task-command. IDE returns to APM with success/failure. success, sets request_queue blocker flag (very critical) APM catches signal and calls for WAKEUP to IDE. IDE issues soft-device rest to get attention of device. (nukes all settings) If supported a channel reset of the HOST also. (even better nuking) while (twiddle thumbs) IDE issues check-power-1 and check-power-2 task-command, until. IDE waits for device ready response. HOST and Device are assumed to be in PIO 0 and this is safe assumption. IDE recovers settings before APM(sleep) and reprograms HOST and Device. IDE returns to APM with success/failure. success, clears request_queue blocker flag (very critical) Requests are now serviced. Does this jive with you? Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
Hi Andre,
Andre Hedrick <[EMAIL PROTECTED]> writes:
>
> You want to get ATA/PI APM fixed?
Absolutely :-)
> "The Linux 'original' IDE guy' Mark Lord showed Alan what was trying to
> bang over everyone's head, without success.
>
> Here is his sample code for cs5530 chipset.
>
> Look at this and comment. I have part of the space setup to complete the
> APM extenstion calls. This will get you and me out of a jam with laptops.
OK, I include below a more or less translation for 2.4. I have not even
compiled this, and have not got the hardware to test it anyway.
However, on the bus this morning, I though about this again and wondered
that this may not the correct way to do this. What we actually want to
power manage is the PCI device as a whole not each interface independantly,
which I would assume is impossible anyway.
2.4 provides another power management interface for PCI drivers - the
suspend and resume elements of the pci_driver struct. These have
the advantage of the driver being called in the correct order with
respect to power being removed/resumed to the bus that the device
is actually hanging off. Unfortunately, the IDE code does not use
the "new" (quoted from Documentation/pci.txt) pci_register_driver
interface.
Also, the suspend/resume logic should include code to actually turn
the device off and on.
Where do we go from here?
Cheers,
Stephen
--
Stephen Rothwell, Open Source Researcher, Linuxcare, Inc.
+61-2-62628990 tel, +61-2-62628991 fax
[EMAIL PROTECTED], http://www.linuxcare.com/
Linuxcare. Support for the revolution.
diff -ruN 2.4.0-test10pre5/drivers/ide/cs5530.c
2.4.0-test10pre5-ide/drivers/ide/cs5530.c
--- 2.4.0-test10pre5/drivers/ide/cs5530.c Wed Oct 4 10:35:09 2000
+++ 2.4.0-test10pre5-ide/drivers/ide/cs5530.c Thu Oct 26 01:09:05 2000
@@ -31,6 +31,23 @@
#define DISPLAY_CS5530_TIMINGS
+#if defined(CONFIG_PM)
+#include
+/*
+ * This driver now supports APM SUSPEND/RESUME actions,
+ * for which it saves/restores chipset/drive timings.
+ *
+ * BUT.. this code may be slightly unsafe to use since
+ * there is no knowlege of APM in the higher level IDE code.
+ *
+ * The risk is that there may be I/O in progress when
+ * our RESUME function is invoked.. and we'll basically toast it.
+ * The high level code will eventually time out on its IRQ wait,
+ * and likely report a "lost interrupt" after assuming the
+ * operation completed successfully. Ugh.
+ */
+#endif
+
#if defined(DISPLAY_CS5530_TIMINGS) && defined(CONFIG_PROC_FS)
#include
#include
@@ -251,7 +268,7 @@
/*
* Initialize the cs5530 bridge for reliable IDE DMA operation.
*/
-unsigned int __init pci_init_cs5530 (struct pci_dev *dev, const char *name)
+unsigned int pci_init_cs5530 (struct pci_dev *dev, const char *name)
{
struct pci_dev *master_0 = NULL, *cs5530_0 = NULL;
unsigned short pcicmd = 0;
@@ -338,12 +355,108 @@
return 0;
}
+#if defined(CONFIG_PM)
+static int cs5530_pm_callback(struct pm_dev *pm_dev, pm_request_t rqst,
+ void *data)
+{
+ static unsigned int saved_regs[2][4];
+ static int saved_state[2];
+ static int already_restored = 1;
+ int h, d, r;
+ unsigned int basereg;
+ unsigned int format;
+ ide_hwif_t *hwif = pm_dev->data;
+ ide_drive_t *drive;
+
+ switch(rqst) {
+ case PM_SUSPEND:
+ if (hwif == NULL)
+ break;
+
+ basereg = CS5530_BASEREG(hwif);
+ h = hwif->index;
+ for (r = 0; r < 4; ++r)
+ saved_regs[h][r] = inl(basereg + (r<<2));
+ saved_state[h] = 1;
+ printk("%s: saved chipset timings\n", hwif->name);
+ already_restored = 0;
+ break;
+
+ case PM_RESUME:
+ if (hwif == NULL)
+ break;
+ h = hwif->index;
+ if (saved_state[h] == 0)
+ break;
+
+ /*
+* Restore chipset registers:
+*/
+ basereg = CS5530_BASEREG(hwif);
+ if (!already_restored++)
+ (void) pci_init_cs5530 (hwif->pci_dev, "CS5530");
+ for (r = 0; r < 4; ++r)
+ outl(saved_regs[h][r], basereg + (r<<2));
+ printk("%s: restored chipset timings\n", hwif->name);
+ /*
+* Re-program drive PIO modes
+*/
+ format = (saved_regs[h][1] >> 31) & 1;
+ for (d = 0; d < MAX_DRIVES; ++d) {
+ drive = &(hwif->drives[d]);
+ if (drive->present) {
+ unsigned int pio, timings;
+ timings = saved_regs[h][d<<1];
+ for (pio = 0; pio <= 4; ++pio)
+ if (cs5530_pio_timings[format][pio] == timings)
+
Re: [PATCH] make my life easier ...
On Wed, Oct 25, 2000 at 01:42:52PM +0200, Martin Mares wrote: > Hello! > > > "The Linux 'original' IDE guy' Mark Lord showed Alan what was trying to > > bang over everyone's head, without success. > > > > Here is his sample code for cs5530 chipset. > > > > Look at this and comment. I have part of the space setup to complete the > > APM extenstion calls. This will get you and me out of a jam with laptops. > > This doesn't make much sense to me: Why don't we just reinitialize the timings > as we do when programming the chipset instead of saving/restoring the state? Aside from all of the other comments that've been made, because the user might have tweeked them at boot. ie turn on UDMA. If we just re-initalized on wakeup, you loose this. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
Followup to: <[EMAIL PROTECTED]> By author:Martin Mares <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > This doesn't make much sense to me: Why don't we just reinitialize the timings > as we do when programming the chipset instead of saving/restoring the state? > > Also, are you sure BIOSes don't save the IDE controller state when suspending? > > Have a nice fortnight > Wrong question. The proper question is "are we not sure the BIOS doesn't save..." and the answer is "with all the buggy BIOSes out there, of course not." Seriously. Relying on the BIOS any more than the absolutely necessary minimum is way dangerous. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
On Wed, 25 Oct 2000, Martin Mares wrote: > Hello! > > > "The Linux 'original' IDE guy' Mark Lord showed Alan what was trying to > > bang over everyone's head, without success. > > > > Here is his sample code for cs5530 chipset. > > > > Look at this and comment. I have part of the space setup to complete the > > APM extenstion calls. This will get you and me out of a jam with laptops. > > This doesn't make much sense to me: Why don't we just reinitialize the timings > as we do when programming the chipset instead of saving/restoring the state? > > Also, are you sure BIOSes don't save the IDE controller state when suspending? Assume BIOS = just enough to appear to work with Windows. My VAIO appears to lose at least the spindown timeout setting, probably more on suspend. It also loses some video state - if I suspend when the screen is blanked by X, restore gets me a white screen of death - no way to make video come back to life. Now that I've got hibernate working, I've figured out that I can hibernate/unhibernate to get the card back into the state X thinks it should be in. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
Hello! > "The Linux 'original' IDE guy' Mark Lord showed Alan what was trying to > bang over everyone's head, without success. > > Here is his sample code for cs5530 chipset. > > Look at this and comment. I have part of the space setup to complete the > APM extenstion calls. This will get you and me out of a jam with laptops. This doesn't make much sense to me: Why don't we just reinitialize the timings as we do when programming the chipset instead of saving/restoring the state? Also, are you sure BIOSes don't save the IDE controller state when suspending? Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "MIPS: Meaningless Indicator of Processor Speed." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
Hello! "The Linux 'original' IDE guy' Mark Lord showed Alan what was trying to bang over everyone's head, without success. Here is his sample code for cs5530 chipset. Look at this and comment. I have part of the space setup to complete the APM extenstion calls. This will get you and me out of a jam with laptops. This doesn't make much sense to me: Why don't we just reinitialize the timings as we do when programming the chipset instead of saving/restoring the state? Also, are you sure BIOSes don't save the IDE controller state when suspending? Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] [EMAIL PROTECTED] http://atrey.karlin.mff.cuni.cz/~mj/ "MIPS: Meaningless Indicator of Processor Speed." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
On Wed, 25 Oct 2000, Martin Mares wrote: Hello! "The Linux 'original' IDE guy' Mark Lord showed Alan what was trying to bang over everyone's head, without success. Here is his sample code for cs5530 chipset. Look at this and comment. I have part of the space setup to complete the APM extenstion calls. This will get you and me out of a jam with laptops. This doesn't make much sense to me: Why don't we just reinitialize the timings as we do when programming the chipset instead of saving/restoring the state? Also, are you sure BIOSes don't save the IDE controller state when suspending? Assume BIOS = just enough to appear to work with Windows. My VAIO appears to lose at least the spindown timeout setting, probably more on suspend. It also loses some video state - if I suspend when the screen is blanked by X, restore gets me a white screen of death - no way to make video come back to life. Now that I've got hibernate working, I've figured out that I can hibernate/unhibernate to get the card back into the state X thinks it should be in. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
Followup to: [EMAIL PROTECTED] By author:Martin Mares [EMAIL PROTECTED] In newsgroup: linux.dev.kernel This doesn't make much sense to me: Why don't we just reinitialize the timings as we do when programming the chipset instead of saving/restoring the state? Also, are you sure BIOSes don't save the IDE controller state when suspending? Have a nice fortnight Wrong question. The proper question is "are we not sure the BIOS doesn't save..." and the answer is "with all the buggy BIOSes out there, of course not." Seriously. Relying on the BIOS any more than the absolutely necessary minimum is way dangerous. -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
On Wed, Oct 25, 2000 at 01:42:52PM +0200, Martin Mares wrote: Hello! "The Linux 'original' IDE guy' Mark Lord showed Alan what was trying to bang over everyone's head, without success. Here is his sample code for cs5530 chipset. Look at this and comment. I have part of the space setup to complete the APM extenstion calls. This will get you and me out of a jam with laptops. This doesn't make much sense to me: Why don't we just reinitialize the timings as we do when programming the chipset instead of saving/restoring the state? Aside from all of the other comments that've been made, because the user might have tweeked them at boot. ie turn on UDMA. If we just re-initalized on wakeup, you loose this. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
On Thu, 26 Oct 2000, Stephen Rothwell wrote: However, on the bus this morning, I though about this again and wondered that this may not the correct way to do this. What we actually want to power manage is the PCI device as a whole not each interface independantly, which I would assume is impossible anyway. Wrong level at this point, IMHO. 2.4 provides another power management interface for PCI drivers - the suspend and resume elements of the pci_driver struct. These have the advantage of the driver being called in the correct order with respect to power being removed/resumed to the bus that the device is actually hanging off. Unfortunately, the IDE code does not use the "new" (quoted from Documentation/pci.txt) pci_register_driver interface. Also, the suspend/resume logic should include code to actually turn the device off and on. If you do this we may end up deregistering the device and unless APM can remember everything the devices/drives may be lost. Where do we go from here? First we thank Mark Lord for putting to 'C' what I was banging on for a while. I thinkered with this with a hotswap ATA-model and have the bases, but I do not want to fill either driver with boat loads of code that will be deleted in 2.5 when I rewrite mine. One of the issues to include is bay-swapping that is critical for the testing. This then falls back upon the bases of hotswap device and not just disks. Here is the event path that I think will work. APM signals ATA/IDE to goto sleep. IDE then records and buffers the setup of the host and device. IDE forces device and host to PIO 0 (imortant step, explain later) IDE issues spindown and sleep task-command. IDE returns to APM with success/failure. success, sets request_queue blocker flag (very critical) APM catches signal and calls for WAKEUP to IDE. IDE issues soft-device rest to get attention of device. (nukes all settings) If supported a channel reset of the HOST also. (even better nuking) while (twiddle thumbs) IDE issues check-power-1 and check-power-2 task-command, until. IDE waits for device ready response. HOST and Device are assumed to be in PIO 0 and this is safe assumption. IDE recovers settings before APM(sleep) and reprograms HOST and Device. IDE returns to APM with success/failure. success, clears request_queue blocker flag (very critical) Requests are now serviced. Does this jive with you? Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
Stephen,
You want to get ATA/PI APM fixed?
"The Linux 'original' IDE guy' Mark Lord showed Alan what was trying to
bang over everyone's head, without success.
Here is his sample code for cs5530 chipset.
Look at this and comment. I have part of the space setup to complete the
APM extenstion calls. This will get you and me out of a jam with laptops.
LT, you in for the patches or tank the laptops until 2.5?
Andre Hedrick
The Linux ATA/IDE guy
--- linux-2.2.18pre15/drivers/block/cs5530.c.orig Wed May 3 20:16:33 2000
+++ linux-2.2.18pre15/drivers/block/cs5530.cMon Oct 16 20:46:11 2000
@@ -1,5 +1,5 @@
/*
- * linux/drivers/block/cs5530.cVersion 0.4 Feb 6, 2000
+ * linux/drivers/block/cs5530.cVersion 0.6 Oct 16, 2000
*
* Copyright (C) 2000 Mark Lord <[EMAIL PROTECTED]>
* May be copied or modified under the terms of the GNU General Public License
@@ -20,6 +20,24 @@
#include
#include
+#ifdef CONFIG_APM
+/*
+ * This driver now supports APM SUSPEND/RESUME actions,
+ * for which it saves/restores chipset/drive timings.
+ *
+ * BUT.. this code may be slightly unsafe to use since
+ * there is no knowlege of APM in the higher level IDE code.
+ *
+ * The risk is that there may be I/O in progress when
+ * our RESUME function is invoked.. and we'll basically toast it.
+ * The high level code will eventually time out on its IRQ wait,
+ * and likely report a "lost interrupt" after assuming the
+ * operation completed successfully. Ugh.
+ */
+#include
+static int cs5530_apm_callback(apm_event_t ae);
+#endif
+
#ifndef SETFEATURES_XFER
#define CS5530_2_2_KERNEL
#endif
@@ -351,7 +369,7 @@
/*
* Initialize the cs5530 bridge for reliable IDE DMA operation.
*/
-unsigned int __init pci_init_cs5530 (struct pci_dev *dev, const char *name)
+unsigned int pci_init_cs5530 (struct pci_dev *dev, const char *name)
{
struct pci_dev *master_0 = NULL, *cs5530_0 = NULL;
unsigned short pcicmd = 0;
@@ -429,6 +447,20 @@
return 0;
}
+#ifdef CONFIG_APM
+/*
+ * UGLY: There really ought to be a way to give/receive
+ * a device tag of some kind for APM callbacks.
+ *
+ * As it stands, we haven't a friggin' clue which hwif
+ * we are being invoked on behalf of. UGLY.
+ *
+ * So.. we have this UGLY global variable to keep track of it.
+ * There can only be two cs5530 hwifs in the hardware.
+ */
+static ide_hwif_t *cs5530_hwifs[2] = {NULL,NULL};
+#endif /* CONFIG_APM */
+
/*
* This gets invoked by the IDE driver once for each channel,
* and performs channel-specific pre-initialization before drive probing.
@@ -442,6 +474,17 @@
(void) pci_init_cs5530 (hwif->pci_dev, "CS5530");
}
#endif /* CS5530_2_2_KERNEL */
+#ifdef CONFIG_APM
+ static int apm_registered = 0;
+
+ cs5530_hwifs[hwif->index] = hwif; /* remember this HWIF for callbacks */
+ if (!apm_registered) {
+ apm_registered = 1;
+ if (apm_register_callback(cs5530_apm_callback)) {
+ printk(KERN_WARNING "%s: apm suspend/resume might not work\n",
+hwif->name);
+ }
+ }
+#endif /* CONFIG_APM */
if (hwif->mate)
hwif->serialized = hwif->mate->serialized = 1;
if (!hwif->dma_base) {
@@ -465,3 +508,108 @@
}
}
}
+
+#ifdef CONFIG_APM
+int cs5530_apm_callback (apm_event_t ae)
+{
+ static unsigned int saved_regs[2][4] = {{0,0,0,0},{0,0,0,0}};
+ static int saved_state = 0;
+ int h, d, r;
+
+ /*
+* UGLY: There really ought to be a way to give/receive
+* a device tag of some kind for APM callbacks.
+*
+* As it stands, we haven't a friggin' clue which hwif
+* we are being invoked on behalf of. UGLY.
+*/
+ switch(ae) {
+ case APM_SYS_SUSPEND:
+ case APM_CRITICAL_SUSPEND:
+ case APM_USER_SUSPEND:
+ for (h = 0; h < 2; ++h) {
+ ide_hwif_t *hwif = cs5530_hwifs[h];
+ if (hwif) {
+ unsigned int basereg = CS5530_BASEREG(hwif);
+ for (r = 0; r < 4; ++r) {
+ saved_regs[h][r] = inl(basereg +
+(r<<2));
+ }
+ printk("%s: saved chipset timings\n",
+hwif->name);
+ }
+ }
+ saved_state = 1;
+ break;
+
+ case APM_NORMAL_RESUME:
+ case APM_CRITICAL_RESUME:
+ case APM_STANDBY_RESUME:
+ if (saved_state) {
+ /*
+
