Subject: Re: power management and idle detection on non-x86
To: Jared D. McNeill <firstname.lastname@example.org>
From: Garrett D'Amore <email@example.com>
Date: 05/08/2006 09:09:28
Jared D. McNeill wrote:
> On Mon, 8 May 2006, Garrett D'Amore wrote:
>> There's a bunch of Linux power management crapola in the video drivers.
>> Sleep/wake is "especially" interesting, because some of these video
>> parts have unique initialization considerations. When running Xwsfb on
>> non-PC hardware, we might need the underlying wsdisplay to do the
> I have concerns about users of servers other than Xwsfb and how they
> will interact if we start buggering with various display registers
> while they're running. I'm sure we can work around them..
Quick thoughts on this (which are heavily influenced from my experience
with Solaris power management): when powering off a device, first call
userland registered parties.
Then shut down user threads.
Then call kernel entities. Kernel entities, e.g. this is where the
kernel radeon driver can simply snapshot the critical registers to
restore them later.
Finally, save kernel and memory state to swap, etc.
On resume, you do the steps in reverse.
The nice thing here is that if e.g. radeonfb(4) is correctly written,
then it can save and restore the registers *as X* had left them. I.e.
Xwsfb and Xradeon do not need to know about *system* display management.
For the purposes of DPMS, etc., perhaps Xradeon should simply arrange to
block whatever blanking that some other entity is using to blank the
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191