RE: Subtle semantic issue with sleep callbacks in drivers

[Patrick Mochel <mochel@osdl.org>]

> 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