Re: Subtle semantic issue with sleep callbacks in drivers

Pavel Machek (pavel@ucw.cz)
Wed, 23 Apr 2003 17:29:28 +0200


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/