From: Jeff Garzik <jgarzik@pobox.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Patrick Mochel <mochel@osdl.org>,
"Grover, Andrew" <andrew.grover@intel.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Subtle semantic issue with sleep callbacks in drivers
Date: Thu, 17 Apr 2003 10:48:44 -0400 [thread overview]
Message-ID: <20030417144844.GC18749@gtf.org> (raw)
In-Reply-To: <1050586549.31414.41.camel@dhcp22.swansea.linux.org.uk>
On Thu, Apr 17, 2003 at 02:35:50PM +0100, Alan Cox wrote:
> On Mer, 2003-04-16 at 19:39, Patrick Mochel wrote:
> > I completely agree with Andy. We should not re-POST the video hardware, no
> > matter what. The idea behind ACPI is that the OS takes care of everything,
> > including video save/restore.
>
> Outside of happyville ivory towers you probably have no choice. Only the
> BIOS knows stuff like the RAM timings, and some windows drivers just use
> the BIOS, others rely on being shipped compiled for the right variant of
> card they came with.
You are exactly right.
The video BIOS on a card often contains information that is found
-nowhere- else. Not in the chip docs. Not in a device driver.
Such information can and does vary from board-to-board, such as RAM
timings, while the chip remains unchanged.
You mention "windows drivers" above... even some Linux X drivers
depend on video BIOS. The S3 Savage XFree86 driver, for example,
uses video BIOS quite heavily unless you tell it not to (or are on
a platform that prevents such).
WRT save and restore, it is certainly possible without video re-POST...
However, support such will require a monumental effort of testing and
debugging for each video board. This monumental effort _will_ include
XFree86 hacking and possibly the additional of some save-n-restore
video drivers, if we do not wish to simply require CONFIG_FBDEV if
CONFIG_SUSPEND is set.
Video re-POST is simply a Real Life(tm) shortcut to that monumental effort.
Jeff, originally an fbdev hacker back in the day...
next prev parent reply other threads:[~2003-04-17 14:36 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-14 21:09 Subtle semantic issue with sleep callbacks in drivers 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 [this message]
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
-- strict thread matches above, loose matches on Subject: below --
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 17:09 Grover, Andrew
2003-04-14 17:40 ` Benjamin Herrenschmidt
2003-04-23 15:29 ` 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=20030417144844.GC18749@gtf.org \
--to=jgarzik@pobox.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.