Notes on Display power management and scope for enhancement
From OMAPpedia
[Following are notes from March-2011]
Contents |
[edit] 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.
[edit] 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.
[edit] 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.
[edit] 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.
[edit] 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
