Re: Sleep on desktop system?
- To: "William C Brennan" <firstname.lastname@example.org>, <email@example.com>
- Subject: Re: Sleep on desktop system?
- From: "Benjamin Herrenschmidt" <firstname.lastname@example.org>
- Date: Wed, 11 Sep 2002 09:55:32 +0200
- Message-id: <email@example.com>
- In-reply-to: <firstname.lastname@example.org>
- References: <email@example.com>
>>I've seen many references to 'pmud' for PowerBooks, but I haven't been
>>able to find any information on putting a desktop system to sleep. Can
>>it be done under Debian/Linux?
>Well, whatever you do, don't install and run pmud on a desktop
>machine. It will lock your machine
>up. Rebooting won't help - once you run pmud it automatically enters
>that hung state with every successive boot. I learned this lesson
>the hard way several months ago.
>And like you, I'm still waiting to see if any sleep application has
>been written for a desktop machine.
Well, the problem isn't simple. Most PowerMac desktop systems
(especially all the recent ones with a PMU chip) can indeed enter
a "deep sleep" state similar to what the laptops can do. Actually,
most of the code to deal with it on laptops would just work on
desktops, with one noticeable exception: PCI cards and especially
the AGP video card.
The difference is that on desktops, the PMU will actually remove
power from the PCI and AGP slots, thus powering down the cards
physically). The problem with that is that some of the drivers
(especially the video ones) can't cope with a card that have been
powered down. They expect some initial setup have been done by
This is typically the case with all video cards. Almost each
modern video chip requires a complicated initialization sequence
involving setting up of the chip's internal clock net, turning
on the various PLLs, configuring the SGRAM controller, etc...
along with blasting a couple of non documented registers controlling
internal chip workarounds ...
So basically, only ATI knows how to power back up an ATI card,
same for nVidia. We could try to make something that would work
in _most_ cases (by mostly backing up some register values and
trying to reproduce some of the above sequences), but that would
be tricky and prone to fail with any new rev. of the chip out there.
Another solution, probably more realistic, would be to have some
kind of small forth interpreter & OF emulator to be able to
re-run the Open Firmware fcode of the card on wakeup. I'm quite
sure the fcode for those cards relies only on a few support
routines from the common OF support packages.
Any volunteer ? :)