Messages in this thread | | | From | "Grover, Andrew" <> | Subject | RE: Subtle semantic issue with sleep callbacks in drivers | Date | Mon, 14 Apr 2003 10:09:12 -0700 |
| |
> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org] > - On non-PPC machines, the slot will eventually go to D3, but > the APM BIOS or ACPI will be able to re-POST the card > properly on wakeup, so the driver only needs to restore the > current display mode, at least I guess so since I don't know > much about x86's. Similar will happen once I have an OF > emulator ready on PPC to re-POST some cards, thus changing > the previous example into this one. In this case, the driver > can put the chip to D3 and can _accept_ the sleep request > because it's explicitely told by the system (how ?) that the > card will be re-POSTED prior to the > resume() callback.
Topic drift...
After asking around internally, it sounds like we should not be doing a video re-POST on wakeup. Windows only used to in order to workaround buggy video drivers, according to what I've heard.
Ben obviously PPC is ahead of the pack on this stuff (congrats) but I did just want to put forward the idea that when we're all done with this stuff on all archs, we will hopefully not be regularly re-POSTing the video bios.
Regards -- Andy - 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/
| |