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

[Alex Deucher]

On 7/31/06, Keith Packard <keithp at keithp.com> wrote:
> 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?

Would it make sense to use the chip's built in standy timer (somehow
linked to the DPMS timer) or just explicitly enable or disable standby
mode when we handle DPMS events?  Some chips may have more fine
grained control over which parts of the chip get shutdown when they
you may want to kick in before a DPMS event (like auto-shutdown of
FIFOs or the overlay when you aren't using it).  I suppose they could
be done as driver specific options.

Alex

>
> > 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
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
>
> iD8DBQBEzY/DQp8BWwlsTdMRAnkkAJ97gj0pCKd1Fq8anbaBl1i2Tjc3vgCghJGU
> v3ihS23gKGpWXBzPC/oR3Io=
> =2qJn
> -----END PGP SIGNATURE-----
>
>
>