More advanced power savings (rev. the DPMS extension).

[Keith Packard]

On Sun, 2006-07-30 at 20:58 -0400, Alex Deucher wrote:

> Just to give another real world example, here an eaxmple of the power
> saving features and limiations available in the siliconmotion lynx
> chips.  The specs are freely available on smi's website for those that
> are intersted.
> 
> 1.  PCI D0-D3 states
> 
> 2.  functional block disabling - the various functional units (PLLs,
> DAC, ZV port, drawing engine, etc.) can be explictily disabled or can
> be controlled on the fly by enabling the chip's auto-standby mode.
> the auto-standby timer is selectable from 0-64 minutes.  see below.

To a great extent, you've already noticed that this can be entirely
automated by the chip, and hence should be nominally invisible to the
user. As much as possible, the driver should do this kind of thing
automatically without any user configuration at all.

> 3. standby/sleep mode - standby: all functional blocks are disabled,
> CRT and FP are blanked, clocks are reduced (selectable).  standby can
> auto-controlled by the chip (see above).  sleep mode must be
> programmed directly, but provides greater power savings.  Sleep modes
> powers down all blocks and clocks and puts the vram into self refresh
> mode.

These seem to map to existing DPMS levels cleanly; is there any need to
expose them separately?

> This could probably be always enabled, however, it would be nice to be
> able to select the timer, perhaps via the DPMS timer? sleep mode could
> be enabled/disabled via DPMS off events.

We may leave the existing DPMS timers around, but the 'normal' mode of
operation would be to leave the DPMS state transitions entirely under
the control of the external screen saver and power manager daemons. The
policy for when to entertain the user with a random screen saver image
and when to save power cannot easily be encapsulated in a random set of
timeouts, so we should just give up and let the client figure out what
it wants. All the X server should do is expose the appropriate
mechanisms to notify clients about idle time (using events with
client-specified timeouts); that seems easy to do with the Sync
extension. DPMS state transitions can be handled by the existing DPMS
extension, although I'd like to allow clients to 'take over' the timeout
policy without having to reset the values; when said clients terminate,
the built-in policy would take over.

> 4. Clock control (ReduceOn) - 2 levels
>  - level 1 - reduce mclk by 25-50%
>  - level2 - level 1, plus reduce core voltage (requires special hardware)
> - limitations - not supported in dualhead mode, no gamma correction,
> some limitations on 3D and video overlay.
> 
> Due to the limitations of "reduceOn" it would be nice to be able to
> turn it on and off on the fly, so you could enable it or disable it
> via ACPI events like the switch from AC to battery, etc.

This looks a lot like the cpufreq stuff; right now, the 'best' policy
we've found for that is to build sensible default behaviour into the
kernel (ondemand), while also exposing it to user mode. I'd like to see
if there isn't a way to eliminate this from the client's view and create
a built-in power management policy for each driver. If we find common
policies, we can look at merging multiple driver mechanisms together.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20060730/667d2832/attachment.pgp>