Notes on Display power management and scope for enhancement

[Following are notes from March-2011]

Current capabilities/features

 * DSS clocks are on when a panel is enabled.
 * Need to figure out entry/exit points from user space and handle clocks there.
 * Currently if any one panel is enabled, some minimum clocks are used. If the panel is a smart panel, we can cut the clocks, but this is not supported currently.


 * Aggresive clock cutting - benefits?
 * for DSI (w/ smart panels) we could turn off the clocks after every frame is sent.
 * need a mechanism for FB/V4L2/DRM to notify DSS2 their frame-rate or their "next expected update".
 * Data needed: h/w time required to go to ULPS and come back out.


 * DSS goes to retention during system wide suspend.
 * DSS can be in retention in cpu idle path if all panels are disabled/suspended.
 * DSS goes to idle and standby when conditions are fulfilled.

Requirements as seen by product teams, customers

 * Low power refresh for DPI and DSI Video Mode panels
 * lpr on dpi panels didn't give much savings -> seen experimentally
 * lowering frame rate helps.
 * Cutting clocks between frames for DSI panels.
 * ULPS for DSI.
 * Cutting clocks using inactivity timer.
 * Frame rate / Timings control for non DPI panels?
 * what is better - should you send data slower, or send data faster and sleep more.
 * for DSI its better to send faster and turn off DSS
 * Ensure idle ack and mstandby get asserted most of the times.
 * optimal configuration of thresholds & fifos will allow longer/quicker assertion of idle-acks or mstandby signals.

Design in L24x/L27x

 * Clocks divided into mainclk and optclocks.
 * Internal use count maintained by driver to keep track if mainclk/optclocks are on or off.
 * Entry/exit points defined where clocks are enabled/disabled.
 * Enabling/disabling clocks decided on the state of all the panels(dssdev->state)
 * Clocks are enabled when the the first panel is enabled/resumed.
 * Clocks are disabled when all the panels are disabled/suspend.
 * Inactivity timer which cuts DSS mainclk and opt-clocks and goes to ON-INACTIVE state.
 * in pm_runtime ensure that context save/restore happens in runtime call back functions that are called before (& after) suspend (& resume). Internal clock usage counts can then be removed.
 * choosing clock source smartly based on what modules/outputs are active ... can this be implemented? This is difficult - one way could be to define the sets / configurations via board file.

Needs/Wishlist

 * Robustness of clock management in multi panel use case (L27x .. open-source code mostly clean/fixed).
 * More efficient DMA FIFO management across pipelines to reduce DMA bursts.
 * fifo-merge (all fifos merge to one - on omap3, .. more flexible sharing in omap4)
 * Debug support for observing idle and standby signals.
 * most likely mux fw provides debugfs nodes to change pinmux. (verify) - if so, it can be used via user-space script. Check out the "debobs" (debug observability) support posted by Peter 'p2' De Schrijver.


 * Dynamic changing of clock frequencies and clock sources.
 * e.g. when scaling is required - bump up the clock, else slow down.
 * imposition of constraints.

Summary of features to be improved in open-source driver

 * pm_runtime (including context save/restore)
 * removal of aggressiveness
 * Imposition of constraints for L3.
 * DSI - ULPS
 * ON-inactive support
 * Fifo merge & optimizing fifo thresholds (for longer mstandby)
 * Choosing clock sources smartly / preconfigured via board file
 * Disabling clocks when possible, for smart panels.
 * Dynamic changing of clock frequencies based on use (e.g. scaling, etc.)
 * Debug support for observability signals


 * BACK to Display Domain Wiki