RE: Subtle semantic issue with sleep callbacks in drivers

Grover, Andrew (andrew.grover@intel.com)
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/