From: "Grover, Andrew" <andrew.grover@intel.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Patrick Mochel <mochel@osdl.org>
Cc: linux-kernel mailing list <linux-kernel@vger.kernel.org>
Subject: RE: Subtle semantic issue with sleep callbacks in drivers
Date: Mon, 14 Apr 2003 10:09:12 -0700 [thread overview]
Message-ID: <F760B14C9561B941B89469F59BA3A84725A260@orsmsx401.jf.intel.com> (raw)
> 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
next reply other threads:[~2003-04-14 16:57 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-14 17:09 Grover, Andrew [this message]
2003-04-14 17:40 ` Subtle semantic issue with sleep callbacks in drivers Benjamin Herrenschmidt
2003-04-23 15:29 ` Pavel Machek
-- strict thread matches above, loose matches on Subject: below --
2003-04-14 21:09 Grover, Andrew
2003-04-16 18:39 ` Patrick Mochel
2003-04-16 19:36 ` Benjamin Herrenschmidt
2003-04-17 13:35 ` Alan Cox
2003-04-17 14:48 ` Jeff Garzik
2003-04-17 15:09 ` John Bradford
2003-04-17 15:09 ` Jeff Garzik
2003-04-17 15:47 ` John Bradford
2003-04-17 15:56 ` Jeff Garzik
2003-04-17 16:24 ` Alan Cox
2003-04-18 7:37 ` Greg KH
2003-04-18 7:51 ` John Bradford
2003-04-18 9:10 ` Russell King
2003-04-18 11:18 ` Alan Cox
2003-04-18 11:30 ` Alan Cox
2003-04-29 8:28 ` Pavel Machek
2003-04-17 14:59 ` John Bradford
2003-04-17 15:04 ` Alan Cox
2003-04-14 19:07 Grover, Andrew
2003-04-14 19:18 ` Benjamin Herrenschmidt
2003-04-14 19:56 ` Alan Cox
2003-04-23 15:34 ` Pavel Machek
2003-04-14 10:00 Benjamin Herrenschmidt
2003-04-14 10:11 ` Benjamin Herrenschmidt
2003-04-16 18:31 ` Patrick Mochel
2003-04-16 19:29 ` Benjamin Herrenschmidt
2003-04-23 15:32 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F760B14C9561B941B89469F59BA3A84725A260@orsmsx401.jf.intel.com \
--to=andrew.grover@intel.com \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).