> Which strikes me as kind of silly since guess who called the ACPI resume
> vector - the BIOS, so why didn't it do whatever stuff then? :) Anyways
> it's not really relevant. The BIOS will never know about add-in cards,
> and my contention is that even these can be woken up properly w/o bios
> repost (after surmounting technical and potential lack-of-documentation
> hurdles, which is why I'd think we would start with an old, ubiquitous,
> thouroughly documented video card as our first guinea pig. Matrox
> Millennium 2, perhaps?)
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.
We may not have the documentation to properly do that for all hardware
currently, but that is something that we have to suck up and deal with.
For now, we go with hardware that we're able to handle.
The drivers that cannot support reinitialization will not be able to
support suspend-to-RAM. When we get to a point where it really becomes an
issue (i.e. after we have decent working code), then we concentrate on
getting the appropriate docuementation (or code itself, source or binary)
to do it correctly.
Trying to figure out if we need to POST or not for different hardware,
based what the driver knows, is going to become quite a mess real fast. I
don't want to deal with the pain, and would rather take the high ground,
even if it means suffering in the short term.
-pat
-
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/
This archive was generated by hypermail 2b29 : Wed Apr 23 2003 - 22:00:19 EST