New Ideas Under Consideration

This wikipage stages new ideas, suggested feature additions, improvements etc. to the PM SW till they get scheduled for development.

HWMOD Framework Enhancements
The HWMOD framework enhancements were discussed as a part of PM workshop held at Bangalore 7-11 Jun, 2010. More details can be found at this link.

They are being scheduled for implementation. Once that is done, more details can be found under HWMOD wiki.

SR Voltage Control Migration to Regulator Framework Drivers

 * This is nothing but phase 4 of SRF replacement work plan.
 * It is well defined and may not take long (may be couple of months?)
 * Current DVFS & SmartReflex work is good enough for OMAP3 & OMAP4. As a result, it can be taken care at a later time
 * Currently being handled by Thomas Petazzoni

CPUFreq Ondemand Improvement to Fix Performance Issues

 * How to improve ondemand governot to deal with Web performance issue, MMC throughput issue...
 * The entire OPP layer and SRF replacement should be in place first before this is taken up
 * Can be taken at a later time (may be during optimization phase)

Policy Framework for Other Voltage Domains

 * Generalization of the CPUFreq for any kind of MPU (DSP, Ducati, IVA, SGX…)
 * Need to decide - whether to do it as a part of CPUFreq or some custom way?
 * May have potential impact on OMAP4 DVFS as the dependencies may not be modeled nicely
 * Can be done on OMAP3/ OMAP4 board
 * Needed in the long run (optimization phase?)

Dynamic Management of SMP Cores

 * How to dynamically shut down a core depending of use case / load?
 * Current ES2.0 PM validation is based on shutting down on core below certain threshold using CPU hotplug
 * The solution is more of shortcut – even on ROM code validation
 * Need to understand the transition latency of hot plug to take out one core; the main question would be – is it really bound? This also influences the threshold decision
 * Looking at the bigger picture, SW design and architecture will require some long term investigative tasks
 * This task requires a closer interactions with HW designers/ ROM code people etc.

CPUIdle Refinement

 * How many c-states? Any reduction possible?
 * should one constraint one core to the other?
 * Migration of IRQs
 * IRQ balancing (under development)

Extend PM QoS to Provide Per Device Granularity

 * Device specific requirements as part of omap device
 * This is a part of the work for latency constraints under SRF replacement
 * The main question is - should it be done in omap specific way or kernel generic way?
 * The generic way is what being proposed – but omap device approach should be good enough example

Memory Hotplug

 * Needs some investigation
 * Will become a requirement at some point of time given that more and more customers are showing interest in it
 * Important from thermal management perspective
 * Will be taken up at a later stage

Improve the PM Debug / Trace Capability

 * Current code is OMAP3 specific and not particularly clean
 * Need ASAP to improve overall debugging

CPUFreq / CPUIdle Instrumentation for Timechart Usage

 * The instrumentation is needed for measurements and profiling
 * Can be combined with the previous task (Improve PM debug/ trace capability)
 * No immediate need to have access to SDP; first the framework be proven and then one can look at measurements

STM / ETB Support to Export HW Information without Lauterbach

 * The feature was descoped on ES1.0; need to check if it is possible on ES2.0
 * Taken on a lower priority as the benefit is more on eliminating the need for external debugger pod

PM Idle Code in I$/D$ Instead of SRAM

 * Already some work done on this
 * Need further investigation
 * More of optimization; can be taken during optimization phase

Latency Modeling

 * C-state instrumentation to better understand/model latency
 * Could be done after the instrumentation is in place
 * Will help in refining the latency modeling
 * Can be taken at a later stage

Dynamic Clock Events

 * Switching between 32k and high-res timers
 * Kernel timer infrastructure is 32k based
 * Can’t be used high-res timer
 * Switching will enable usage of high res timer along with PM
 * Involves dynamically enabling and disabling clock event source
 * More of optimization; can be taken up at later stage