Messages in this thread | | | Date | Wed, 23 Apr 2003 17:29:28 +0200 | From | Pavel Machek <> | Subject | Re: Subtle semantic issue with sleep callbacks in drivers |
| |
Hi!
> > - 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.
We really should not be doing that, but we... kind of have to. Thats why acpi_sleep=s3_bios exists. I really don't know how to work around it. Pavel -- When do you have a heart between your knees? [Johanka's followup: and *two* hearts?] - 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/
| |