> 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.
If I understand Alan properly, we don't always have choice, some BIOSes
will do it anyway...
> 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.
It is now already ! I don't think we will _ever_ get ATI and nVidia
provide enough documentation to POST all chip models (which isn't always
possible without knowledge of every single way the chip is wired on a
each board).
Currently, I cannot implement suspend-to-RAM on the latest PowerBooks
because of that (they use nVidia chip that are powered down and not just
unclocked unlike earlier ATI based models) because of that. Nor can I
implement it on any other "desktop" Mac.
> 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.
When I finally have an implementation of an OF runtime so I can re-POST
the card, I could eventually have the driver itself call this to explicitely
ask for a re-POST...
Ben.
-
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/